Bug 827519
| Summary: | "Unable to determine device index for network device" when attaching new network device to a guest that already has a netdev of type='hostdev' | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 6 | Reporter: | Laine Stump <laine> | ||||
| Component: | libvirt | Assignee: | Laine Stump <laine> | ||||
| Status: | CLOSED ERRATA | QA Contact: | Virtualization Bugs <virt-bugs> | ||||
| Severity: | unspecified | Docs Contact: | |||||
| Priority: | unspecified | ||||||
| Version: | 6.3 | CC: | acathrow, ajia, dallan, dyasny, dyuan, jwest, mzhan, rwu, whuang, ydu | ||||
| Target Milestone: | rc | ||||||
| Target Release: | --- | ||||||
| Hardware: | Unspecified | ||||||
| OS: | Unspecified | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | libvirt-0.9.13-3.el6 | Doc Type: | Bug Fix | ||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2013-02-21 07:16:06 UTC | Type: | Bug | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Attachments: |
|
||||||
Patch is committed upstream:
commit 6734ce7bc8ec4da7900080aa17fef20c68d401ef
Author: Laine Stump <laine>
Date: Fri Jun 1 12:50:37 2012 -0400
qemu: fix netdev alias name assignment wrt type='hostdev'
The issue has been verified on RHEL6.3(2.6.32-280.el6.x86_64) with libvirt-0.9.13-3.el6.x86_64 and qemu-kvm-rhev-0.12.1.2-2.297.el6_3.x86_64, we can get expected result:
# lspci|grep 82576
03:00.0 Ethernet controller: Intel Corporation 82576 Gigabit Network Connection (rev 01)
03:00.1 Ethernet controller: Intel Corporation 82576 Gigabit Network Connection (rev 01)
03:10.0 Ethernet controller: Intel Corporation 82576 Virtual Function (rev 01)
03:10.1 Ethernet controller: Intel Corporation 82576 Virtual Function (rev 01)
03:10.2 Ethernet controller: Intel Corporation 82576 Virtual Function (rev 01)
03:10.3 Ethernet controller: Intel Corporation 82576 Virtual Function (rev 01)
03:10.4 Ethernet controller: Intel Corporation 82576 Virtual Function (rev 01)
03:10.5 Ethernet controller: Intel Corporation 82576 Virtual Function (rev 01)
03:10.6 Ethernet controller: Intel Corporation 82576 Virtual Function (rev 01)
03:10.7 Ethernet controller: Intel Corporation 82576 Virtual Function (rev 01)
03:11.0 Ethernet controller: Intel Corporation 82576 Virtual Function (rev 01)
03:11.1 Ethernet controller: Intel Corporation 82576 Virtual Function (rev 01)
03:11.2 Ethernet controller: Intel Corporation 82576 Virtual Function (rev 01)
03:11.3 Ethernet controller: Intel Corporation 82576 Virtual Function (rev 01)
03:11.4 Ethernet controller: Intel Corporation 82576 Virtual Function (rev 01)
03:11.5 Ethernet controller: Intel Corporation 82576 Virtual Function (rev 01)
# cat hostdev.xml
<interface type='hostdev' managed='yes'>
<source>
<address type='pci' domain='0x0000' bus='0x03' slot='0x10' function='0x1'/>
</source>
</interface>
# virsh edit myVF with above XML content
# virsh dumpxml myVF
<domain type='kvm' id='9'>
<name>myVF</name>
......
<devices>
......
<interface type='network'>
<mac address='52:54:00:81:94:f7'/>
<source network='default'/>
<target dev='vnet0'/>
<model type='virtio'/>
<alias name='net0'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/>
</interface>
<interface type='hostdev' managed='yes'>
<mac address='52:54:00:ec:f2:6d'/>
<source>
<address type='pci' domain='0x0000' bus='0x03' slot='0x10' function='0x1'/>
</source>
<alias name='hostdev0'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x0'/>
</interface>
......
</devices>
......
</domain>
# modprobe -r kvm_intel kvm
# modprobe kvm allow_unsafe_assigned_interrupts=1
# modprobe kvm_intel
# virsh start myVF
Domain myVF started
# virsh attach-interface myVF network default --model virtio
Interface attached successfully
# virsh dumpxml myVF
<domain type='kvm' id='9'>
<name>myVF</name>
......
<devices>
......
<interface type='network'>
<mac address='52:54:00:81:94:f7'/>
<source network='default'/>
<target dev='vnet0'/>
<model type='virtio'/>
<alias name='net0'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/>
</interface>
<interface type='hostdev' managed='yes'>
<mac address='52:54:00:ec:f2:6d'/>
<source>
<address type='pci' domain='0x0000' bus='0x03' slot='0x10' function='0x1'/>
</source>
<alias name='hostdev0'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x0'/>
</interface>
<interface type='network'>
<mac address='52:54:00:11:2f:1a'/>
<source network='default'/>
<target dev='vnet1'/>
<model type='virtio'/>
<alias name='net1'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x08' function='0x0'/>
</interface>
......
</devices>
......
</domain>
Hi,Laine
When I try this bug with :
libvirt-0.10.2-10.el6.x86_64
qemu-kvm-0.12.1.2-2.340.el6.x86_64
I can not get the expect result but error,
1) attach xml like bellow hostdev is a VF :
...
<interface type='hostdev' managed='yes'>
<mac address='52:54:00:ab:8d:40'/>
<source>
<address type='pci' domain='0x0000' bus='0x03' slot='0x10' function='0x3'/>
</source>
<address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x0'/>
</interface>
...
2) try to start domain :
# virsh start q64
error: Failed to start domain q64
error: An error occurred, but the cause is unknown
libvirtd.log
2012-12-12 08:08:20.431+0000: 5181: error : virFileReadAll:457 : Failed to open file '/var/run/libvirt/qemu/eth1_vf1': No such file or directory
2012-12-12 08:08:20.431+0000: 5181: error : qemuRemoveCgroup:756 : internal error Unable to find cgroup for q64
2012-12-12 08:08:20.431+0000: 5181: warning : qemuProcessStop:4210 : Failed to remove cgroup for q64
Is there any suggestion about this error ?
The real error is happening sometime before the virFileReadAll error, but is apparently missing a proper log message. I can think of two things to try: 1) try changing this from <interface type='hostdev'> to <hostdev> and see if the attach is successful. If it isn't, maybe there will be a better message. If it is, then we can eliminate a lot of potential failure points. 2) try turning the log level up to debug, at least for qemu* and pci*, and post the log somewhere. I can see a couple of places where a debug log is given on a filure path, but no error log. 3) If it's possible to send me the credentials to the machine, and it is free during daytime in the U.S., I can try this operation with gdb attached to libvirtd to try and see the location of the original error. I believe it's somewhere during qemuPrepareHostdevPCIDevices, but have no idea beyond that. Created attachment 664729 [details]
libvirtd log debug enabled
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHSA-2013-0276.html |
Description of problem: On a guest that has a network device of type='hostdev', e.g.: <interface type='hostdev' managed='yes'> <mac address='52:54:00:3b:3e:02'/> <source> <address type='pci' domain='0x0000' bus='0x03' slot='0x10' function='0x1'/> </source> </interface> if you attempt to hotplug an additional network device, the attach will fail with the error: Unable to determine device index for network device Version-Release number of selected component (if applicable): libvirt-0.9.10-21 How reproducible: 100% Steps to Reproduce: 1. On a host that supports PCI passthrough and has an SRIOV-capable network card (e.g. Intel 82576), create a domain that includes a device similar to the XML above (with the PCI address modified to match the PCI address of one of the SRIOV netcard's VFs). 2. Start the domain. 3. "virsh attach-interface $guestname network default --model virtio" Actual results: error: Failed to attach interface error: Unable to determine device index for network device Expected results: Device attached successfully Additional info: There would also be a failure at domain startup if a domain's config listed a non-hostdev <interface> after a type='hostdev' interface. This is caused by the qemuAssignDeviceNetAlias(), which cycles through existing netdevs to decide on an "alias" name to use for the device when talking to qemu. That function expects existing netdevs to all have an alias of the form "net%d". type='hostdev' devices have an alias of the form "hostdev%d" though (because as far as qemu is concerned, they are a hostdev). The problem is that failure to match the expected "net%d" format results in failure. I have a simple patch which remedies this problem which I will be posting upstream as soon as I get the number of this BZ to put in the commit message.