error: Failed to start domain guest1
error: internal error: missing IFLA_VF_INFO in netlink response
Please note that this error is not reproducible using libnl3_2_22. I am currently
working to bisect and identify the offending commit and propose a backport to Ubuntu Trusty.
Hello,
I am able to reproduce this bug consistently on a Trusty (3.19.0-73-generic) machine
equipped with 2 ixgbe 10GbE cards:
04:00.0 Ethernet controller: Intel Corporation Ethernet Controller 10-Gigabit X540-AT2 (rev 01)
04:00.1 Ethernet controller: Intel Corporation Ethernet Controller 10-Gigabit X540-AT2 (rev 01)
The sequence to reproduce this bug is:
1) Edit /etc/default/grub
GRUB_CMDLINE_ LINUX=" intel_iommu= on ixgbe.max_vfs=63"
2) $ sudo update-grub
### Reboot the machine.
3) Check that the virtual functions are available:
$ sudo lspci|grep -i eth | grep -i virtual | wc -l
126
4) Create a KVM guest
$ sudo uvt-kvm create guest1 release=trusty
5) List the VF devices :
$ sudo lspci|grep -i eth | grep -i virtual | awk '{print $1}' | sed 's/\:/\_/g' | sed 's/\./\_/g' > devices.txt
6) Get the libvirt node device:
$ sudo for device in $(cat ./devices.txt); do virsh nodedev-list | grep $device; done > pci_devices.txt
7) Generate the XML config for each device:
$ sudo mkdir devices && for d in $(cat pci_devices.txt); do virsh nodedev-dumpxml $d > devices/$d.xml; done
8) Save and Run the following script (http:// pastebin. ubuntu. com/23374186/)
$ sudo python generate- interfaces. py |grep address | wc -l
9) Finally attach the devices to the guest.
$ sudo for i in $(seq 0 63); do virsh attach-device guest1 ./interfaces/$i.xml --config; done
Device attached successfully
[...]
Device attached successfully
Device attached successfully
10) Then destroy/start the guest again, at this point the error is reproduced.
$ sudo virsh destroy guest1
Domain guest1 destroyed
$ sudo virsh start guest1
error: Failed to start domain guest1
error: internal error: missing IFLA_VF_INFO in netlink response
Please note that this error is not reproducible using libnl3_2_22. I am currently
working to bisect and identify the offending commit and propose a backport to Ubuntu Trusty.