action #29419
closed
[tools] MULTINET parameter cause incomplete job
Added by asmorodskyi over 6 years ago.
Updated over 5 years ago.
Category:
Feature requests
Description
According to https://github.com/os-autoinst/os-autoinst/blob/master/doc/networking.md
MULTINET parameter giving ability to have SUT with two network cards
when running job on 4.5.1512119921.b2fe214f-12.1 with MULTINET parameter I get qemu exception :
QEMU: qemu-system-x86_64: -net nic,vlan=1,model=virtio-net,macaddr=52:54:00:12:34:57: 'vlan' is deprecated. Please use 'netdev' instead.
Files
this issue blocks wicked testing
- Category set to 132
- Target version set to Ready
well, if it blocks you - downgrade to the qemu version this documentation was written for.
it fails also on osd https://openqa.suse.de/tests/1323658. Not sure if problem is the same but nevertheless I can influence on version of qemu in osd but I need to make it work there too
small clarification - when I stated that it's blocks wicked testing I did mean that it's fully block , just all test cases which require second network card ( really approx. 10% of all tests )
- Related to action #32968: [kernel][tools] Refactor QEMU backend - Create QEMU process manager and save configuration state added
- Status changed from New to In Progress
- Assignee set to mkittler
- Target version changed from Ready to Current Sprint
I can reproduce this by cloning the mentioned o3 job locally. Let's see whether I can adjust the invocation of qemu to use 'netdev' instead.
I invested some time into this ticket today. In attachment you can find patch which fixing current issue.
Current issue consists from two problems :
- deprecated "vlan" option
- fault usage of NICMODEL variable for nic model
with applying my patch you will get two nics in SUT . I haven't create a real PR from my patch because actually you will get only one of them in operable state . second nic create exactly in patch is not assigned to any virtual network so it is not clear if there any chance to use it
@asmorodskyi Ok. I've tried your patch and yes - it isn't connected to any virtual network. I believe that the -net nic... option added by your patch is not sufficient. It only creates the device the guest sees but not the backend on the host-side. I'll look into this. Likely there's just a further option missing.
- Status changed from In Progress to Resolved
Also available in: Atom
PDF