Bug 979330 - The driver in output of virsh command nodedev-dumpxml should be updated timely
Summary: The driver in output of virsh command nodedev-dumpxml should be updated timely
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: libvirt
Version: 6.4
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: rc
: ---
Assignee: Laine Stump
QA Contact: Virtualization Bugs
URL:
Whiteboard:
Keywords:
Depends On: 979290
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-06-28 08:56 UTC by Xuesong Zhang
Modified: 2013-11-21 09:04 UTC (History)
6 users (show)

(edit)
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.
Clone Of: 979290
(edit)
Last Closed: 2013-11-21 09:04:46 UTC


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2013:1581 normal SHIPPED_LIVE libvirt bug fix and enhancement update 2013-11-21 01:11:35 UTC

Comment 2 Laine Stump 2013-07-01 05:09:14 UTC
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 07:19:30 UTC
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 09:04:46 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/RHBA-2013-1581.html


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