Bug 618484

Summary: [Intel 6.0 Bug] [libvirt] libvirt doesn't release the virt slot when detach device
Product: Red Hat Enterprise Linux 6 Reporter: yang <yang.z.zhang>
Component: libvirtAssignee: Jiri Denemark <jdenemar>
Status: CLOSED CURRENTRELEASE QA Contact: Virtualization Bugs <virt-bugs>
Severity: high Docs Contact:
Priority: low    
Version: 6.0CC: chrisw, dallan, ddugger, ddutile, eblake, jane.lv, jdenemar, jiajun.xu, jialiu, jlv, jvillalo, luyu, mjenner, rpacheco, syeghiay, xen-maint, xin.li, xudong.hao, yongkang.you
Target Milestone: rcKeywords: RHELNAK
Target Release: 6.0   
Hardware: x86_64   
OS: Linux   
Fixed In Version: libvirt-0_8_1-22_el6 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2010-11-11 14:50:25 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
Bug Depends On:    
Bug Blocks: 551128    

Description yang 2010-07-27 03:11:12 UTC
Description of problem:
In RHEL6 sp7, hotpulg/unplug is work well with libvirt. In our stree test case that hotplug/unplug device many times by libvirt, we always meet the error:
internal error no more avaliable PCI address.
But we don't see it with qemu command-line. After investigation, we observed that device's BDF in guest alway increase when we do hotplug/unplug by libvirt. But for one bus, there only 32 avaliable device ID to use. So if we try hotplug/unplug at most 32 times, libvirt will don't have available BDF for the device to use and it will fail.
With qemu command-line, qemu always use the same BDF for device to use. it seems that libvirt doesnt' release the virt slot when detach the device.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Get RHEL6 sp7, install it as host
2. Use virtualmanager, install RHEL6 sp7 as guest
3. Use "virsh create config.xml" to boot up
4. Use "virsh attach-device "and "virsh detach-device" to hotplug/unplug at most 32 times, you wiil see the error.

Actual results:
hotplug/unplug fails

Expected results:
hotplug/unplug work well

Additional info:

Comment 2 RHEL Product and Program Management 2010-07-27 03:37:40 UTC
This issue has been proposed when we are only considering blocker
issues in the current Red Hat Enterprise Linux release.

** If you would still like this issue considered for the current
release, ask your support representative to file as a blocker on
your behalf. Otherwise ask that it be considered for the next
Red Hat Enterprise Linux release. **

Comment 3 Jiri Denemark 2010-07-29 13:21:14 UTC
The problem is that libvirt autogenerates host PCI address for each device which doesn't have it predefined in the XML. However, once the device is detached, libvirt still remembers that PCI address as occupied and selects another one on next attach-device. So it's easy to run out of PCI addresses. This problem doesn't occur when a device with predefined host PCI address is repeatedly attached/detached.

Comment 8 Dave Allan 2010-08-11 02:49:36 UTC
libvirt-0_8_1-22_el6 has been built in RHEL-6-candidate with the fix.


Comment 10 Johnny Liu 2010-08-20 03:20:58 UTC
Verify this bug with libvirt-0.8.1-27.el6.x86_64, and PASSED.

Reproduce this bug with libvirt-0.8.1-21.el6.x86_64. This bug is gone on libvirt-0.8.1-27.el6.x86_64.

The following is my steps:
1. Create and start a domain.
2. Prepare a xml as following:
    <interface type='network'>
      <mac address='52:54:00:80:d9:bb'/>
      <source network='default'/>
      <model type='rtl8139'/>
3. Hotplug/hot-unplug the PCI device at most 32 times via virsh command:
# for i in `seq 32`; do echo "---${i}---"; virsh attach-device test nic-hostput.xml; sleep 3; virsh detach-device test nic-hostput.xml; sleep 3; done

On libvirt-0.8.1-27.el6.x86_64, it works fine.

Comment 11 yang 2010-08-25 02:44:34 UTC
Verified this bug with rhel6 snap11, and PASSED.

relevant version:

Comment 12 releng-rhel@redhat.com 2010-11-11 14:50:25 UTC
Red Hat Enterprise Linux 6.0 is now available and should resolve
the problem described in this bug report. This report is therefore being closed
with a resolution of CURRENTRELEASE. You may reopen this bug report if the
solution does not work for you.