This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 827519 - "Unable to determine device index for network device" when attaching new network device to a guest that already has a netdev of type='hostdev'
"Unable to determine device index for network device" when attaching new netw...
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: libvirt (Show other bugs)
6.3
Unspecified Unspecified
unspecified Severity unspecified
: rc
: ---
Assigned To: Laine Stump
Virtualization Bugs
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-06-01 12:45 EDT by Laine Stump
Modified: 2013-02-21 02:16 EST (History)
10 users (show)

See Also:
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 02:16:06 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
libvirtd log debug enabled (1.53 MB, application/x-xz)
2012-12-17 03:59 EST, Huang Wenlong
no flags Details

  None (edit)
Description Laine Stump 2012-06-01 12:45:45 EDT
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.
Comment 2 Laine Stump 2012-06-01 13:31:00 EDT
Patch is committed upstream:

commit 6734ce7bc8ec4da7900080aa17fef20c68d401ef
Author: Laine Stump <laine@laine.org>
Date:   Fri Jun 1 12:50:37 2012 -0400

    qemu: fix netdev alias name assignment wrt type='hostdev'
Comment 9 Alex Jia 2012-07-24 23:58:26 EDT
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>
Comment 10 Huang Wenlong 2012-12-12 03:10:33 EST
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 ?
Comment 11 Laine Stump 2012-12-17 02:52:37 EST
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.
Comment 13 Huang Wenlong 2012-12-17 03:59:31 EST
Created attachment 664729 [details]
libvirtd log debug enabled
Comment 16 errata-xmlrpc 2013-02-21 02:16:06 EST
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

Note You need to log in before you can comment on or make changes to this bug.