Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.

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: libvirtAssignee: Laine Stump <laine>
Status: CLOSED ERRATA QA Contact: Virtualization Bugs <virt-bugs>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 6.3CC: 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:
Description Flags
libvirtd log debug enabled none

Description Laine Stump 2012-06-01 16:45:45 UTC 
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 17:31:00 UTC 
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'
Comment 9 Alex Jia 2012-07-25 03:58:26 UTC 
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 08:10:33 UTC 
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 07:52:37 UTC 
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 08:59:31 UTC 
Created attachment 664729 [details]
libvirtd log debug enabled
Comment 16 errata-xmlrpc 2013-02-21 07:16:06 UTC 
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