Bug 979330 - The driver in output of virsh command nodedev-dumpxml should be updated timely
The driver in output of virsh command nodedev-dumpxml should be updated timely
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: libvirt (Show other bugs)
6.4
Unspecified Unspecified
medium Severity medium
: rc
: ---
Assigned To: Laine Stump
Virtualization Bugs
:
Depends On: 979290
Blocks:
  Show dependency treegraph
 
Reported: 2013-06-28 04:56 EDT by Xuesong Zhang
Modified: 2013-11-21 04:04 EST (History)
6 users (show)

See Also:
Fixed In Version: libvirt-0.10.2-19.el6
Doc Type: Bug Fix
Doc Text:
Cause: libvirt was depending on a "change" notification from the kernel to indicate that it should change the name of the device driver bound to a device. That change notification is not actually being sent. Consequence: the output of "virsh nodedev-dumpxml" for a device would always show the device driver that was bound to the device at the time libvirt was started, NOT the currently-bound driver. Fix: libvirt now manually updates the driver name every time a nodedev-dumpxml is done, rather than depending on a change notification. Result: The driver name in the output of nodedev-dumpxml is now always correct.
Story Points: ---
Clone Of: 979290
Environment:
Last Closed: 2013-11-21 04:04:46 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Comment 2 Laine Stump 2013-07-01 01:09:14 EDT
A fix for this bug was pushed upstream and will be in libvirt-1.1.0. Please see Bug 979290 for more details/discussion:

commit 374c5e4f73577b316fed19bbcefe74b75195eb95
Author: Laine Stump <laine@laine.org>
Date:   Sun Jun 30 14:49:21 2013 -0400

    node device driver: update driver name during dumpxml
    
 
    The node device driver was written with the assumption that udev would
    use a "change" event to notify libvirt of any change to device status
    (including the name of the driver it was bound to). It turns out this
    is not the case (see Comment 4 of BZ 979290). That means that a
    dumpxml for a device would always show whatever driver happened to be
    bound at the time libvirt was started (when the node device cache was
    built).
    
    There was already code in the driver (for the benefit of the HAL
    backend) that updated the driver name from sysfs each time a device's
    info was retrieved from the cache. This patch just enables that manual
    update for the udev backend as well.
Comment 5 EricLee 2013-07-10 03:19:30 EDT
Verifying this bug with libvirt-0.10.2-19.el6:

---------------------------------------------
Reproduced with libvirt-0.10.2-18.el64_9:
1. check the pci driver with virsh command nodedev-dumpxml.
# virsh nodedev-dumpxml pci_0000_04_00_0
<device>
  <name>pci_0000_04_00_0</name>
  <parent>pci_0000_00_1e_0</parent>
  <driver>
    <name>e1000</name>
  </driver>
  <capability type='pci'>
    <domain>0</domain>
    <bus>4</bus>
    <slot>0</slot>
    <function>0</function>
    <product id='0x107c'>82541PI Gigabit Ethernet Controller</product>
    <vendor id='0x8086'>Intel Corporation</vendor>
  </capability>
</device>

2. check it's driver with kernel command
# readlink -f /sys/bus/pci/devices/0000\:04\:00.0/driver/
/sys/bus/pci/drivers/e1000

3. change the pci's driver to others, such as change from driver e1000 to driver pci-stub
# virsh nodedev-detach pci_0000_04_00_0
Device pci_0000_04_00_0 detached

4. check the driver with kernel command again, it is changed to pci-stub
# readlink -f /sys/bus/pci/devices/0000\:04\:00.0/driver/
/sys/bus/pci/drivers/pci-stub

5. check the driver with virsh command nodedev-dumpxml, it didn't be updated.
# virsh nodedev-dumpxml pci_0000_04_00_0
<device>
  <name>pci_0000_04_00_0</name>
  <parent>pci_0000_00_1e_0</parent>
  <driver>
    <name>e1000</name>
  </driver>
  <capability type='pci'>
    <domain>0</domain>
    <bus>4</bus>
    <slot>0</slot>
    <function>0</function>
    <product id='0x107c'>82541PI Gigabit Ethernet Controller</product>
    <vendor id='0x8086'>Intel Corporation</vendor>
  </capability>
</device>

---------------------------------------------
Verfied with libvirt-0.10.2-19.el6:
1. check the pci driver with virsh command nodedev-dumpxml.
# virsh nodedev-dumpxml pci_0000_04_00_0
<device>
  <name>pci_0000_04_00_0</name>
  <parent>pci_0000_00_1e_0</parent>
  <driver>
    <name>e1000</name>
  </driver>
  <capability type='pci'>
    <domain>0</domain>
    <bus>4</bus>
    <slot>0</slot>
    <function>0</function>
    <product id='0x107c'>82541PI Gigabit Ethernet Controller</product>
    <vendor id='0x8086'>Intel Corporation</vendor>
  </capability>
</device>

2. check it's driver with kernel command
# readlink -f /sys/bus/pci/devices/0000\:04\:00.0/driver/
/sys/bus/pci/drivers/e1000

3. change the pci's driver to others, such as change from driver e1000 to driver pci-stub
# virsh nodedev-detach pci_0000_04_00_0
Device pci_0000_04_00_0 detached

4. check the driver with kernel command again, it is changed to pci-stub
# readlink -f /sys/bus/pci/devices/0000\:04\:00.0/driver/
/sys/bus/pci/drivers/pci-stub

5. check the driver with virsh command nodedev-dumpxml:
# virsh nodedev-dumpxml pci_0000_04_00_0
<device>
  <name>pci_0000_04_00_0</name>
  <parent>pci_0000_00_1e_0</parent>
  <driver>
    <name>pci-stub</name>
  </driver>
  <capability type='pci'>
    <domain>0</domain>
    <bus>4</bus>
    <slot>0</slot>
    <function>0</function>
    <product id='0x107c'>82541PI Gigabit Ethernet Controller</product>
    <vendor id='0x8086'>Intel Corporation</vendor>
  </capability>
</device>

Driver was updated exactly.

So setting VERIFIED.
Comment 7 errata-xmlrpc 2013-11-21 04:04:46 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/RHBA-2013-1581.html

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