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 979330

Summary:	The driver in output of virsh command nodedev-dumpxml should be updated timely
Product:	Red Hat Enterprise Linux 6	Reporter:	Xuesong Zhang <xuzhang>
Component:	libvirt	Assignee:	Laine Stump <laine>
Status:	CLOSED ERRATA	QA Contact:	Virtualization Bugs <virt-bugs>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	6.4	CC:	acathrow, bili, cwei, dyuan, honzhang, laine
Target Milestone:	rc
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
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 09:04:46 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:
Bug Depends On:	979290
Bug Blocks:

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>
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