Bug 850695 - PCI addresses is changed when removing device
PCI addresses is changed when removing device
Status: CLOSED CANTFIX
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: libvirt (Show other bugs)
5.9
Unspecified Unspecified
high Severity high
: rc
: ---
Assigned To: Martin Kletzander
Virtualization Bugs
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-08-22 03:32 EDT by hongming
Modified: 2012-08-28 09:21 EDT (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-08-28 09:21:02 EDT
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)
Description hongming 2012-08-22 03:32:54 EDT
Description of problem:
The PCI addresses is changed when removing device.

Version-Release number of selected component (if applicable):
kernel-2.6.18-336.el5
libvirt-0.8.2-29.el5
kvm-83-259.el5


How reproducible:
100% 

Steps to Reproduce:
1. Start a linux guest with two PCI NICs (such as: 1th NIC is of 8139 model and 2th NIC is fo e1000 model)


2. Check the PCI slot numbers of the two NIC in guest using lspci command.


  <interface type='network'>
      <mac address='52:54:00:48:0f:b6'/>
      <source network='default'/>
      <target dev='vnet0'/>
      <model type='rtl8139'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/>
    </interface>
    <interface type='network'>
      <mac address='52:54:00:7b:d7:67'/>
      <source network='default'/>
      <target dev='vnet1'/>
      <model type='e1000'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/>
    </interface>


3. Shutdown the guest

4. Remove the 1th NIC ( 8139 model) and start the guest,and also check the address in guest using lspci command. 

    <interface type='network'>
      <mac address='52:54:00:7b:d7:67'/>
      <source network='default'/>
      <target dev='vnet0'/>
      <model type='e1000'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/>
    </interface>

Actual results:
The slot number of the 2th NIC has changed from 4 to 3

Expected results:
The slot number of the 2th NIC hasn't changed

Additional info:
Comment 1 hongming 2012-08-22 03:40:59 EDT
In rhel6, the target name is changed but the pci address is kept.Target name will only show in the # virsh dumpxml domain but not # virsh edit.
Comment 2 RHEL Product and Program Management 2012-08-22 04:18:27 EDT
This request was evaluated by Red Hat Product Management for inclusion
in a Red Hat Enterprise Linux release.  Product Management has
requested further review of this request by Red Hat Engineering, for
potential inclusion in a Red Hat Enterprise Linux release for currently
deployed products.  This request is not yet committed for inclusion in
a release.
Comment 3 Martin Kletzander 2012-08-28 09:21:02 EDT
This is caused by an old hypervisor (in this case kvm) that, in this version, doesn't accept devices a '-device' parameters, but rather as '-net' and so on. With these parameters there is no way to tell kvm what addresses these should have. Rather than removing the address information, we supply it to the user (e.g. in case there is newer kvm when the guest will be started), but when the guest is started, kvm will fill out all the space (in this case slot 3) with specified devices and so we can throw the information away (we have to supply correct information to the user). When the domain is destroyed, there is no reason to keep the address information and so it's not saved.

Having newer kvm would solve your issue (you can search for the string '-device' in its '-help' output to see whether it'll work or not), but I believe this is not possible for RHEL5, so I'm closing this as CANTFIX. Feel free to reopen this bug in case you disagree with this opinion.

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