Bug 500217

Upstream fix for this:

  http://libvirt.org/git/?p=libvirt.git;a=commitdiff;h=4035152a87

libvirt-0.6.3-23.el5 has been built in dist-5E-qu-candidate with
the patches,

Daniel

This bug still exist with libvirt-0.6.3-23.el5 on rhel5u5,and it will raise different result if setting managed mode to 'yes' for xen and hypervisor:

1.xen hypervisor
The function can't be supported by the xen hypervisor,it will raise a error message:

error: Failed to start domain rhel5u5_x86_64_xenfv
error: POST operation failed: xend_post: error from xen daemon: (xend.err 'Error creating domain: pci: PCI Backend does not own device 0000:00:19.0\nSee the pciback.hide kernel command-line parameter or\nbind your slot/device to the PCI backend using sysfs')


2.kvm hypervisor
It can't still automatically re-attach the assigned device after guest be shut down,see following steps to reproduce:

[root@dhcp-66-70-62 ~]# virsh nodedev-list --tree
computer
  |
  +-pci_8086_10bd
  |   |
  |   +-net_00_23_ae_6f_f1_d7
  |
  +-pci_8086_244e
  +-pci_8086_2914
......

[root@dhcp-66-70-62 ~]# virsh nodedev-dumpxml pci_8086_10bd
<device>
  <name>pci_8086_10bd</name>
  <parent>computer</parent>
  <capability type='pci'>
    <domain>0</domain>
    <bus>0</bus>
    <slot>25</slot>
    <function>0</function>
    <product id='0x10bd'>82566DM-2 Gigabit Network Connection</product>
    <vendor id='0x8086'>Intel Corporation</vendor>
  </capability>
</device>

[root@dhcp-66-70-62 ~]# readlink /sys/bus/pci/devices/0000\:00\:19.0/driver/ -f
/sys/bus/pci/drivers/e1000e

[root@dhcp-66-70-62 ~]# virsh edit rhel5u5
Domain rhel5u5 XML configuration edited.

[root@dhcp-66-70-62 ~]# virsh dumpxml rhel5u5
<domain type='qemu'>
  <name>rhel5u5</name>
  <uuid>c0e805d9-e288-e4e8-2357-13b39d57cb6e</uuid>
  <memory>1048576</memory>
  <currentMemory>1048576</currentMemory>
  <vcpu>1</vcpu>
  <os>
    <type arch='x86_64' machine='pc'>hvm</type>
    <boot dev='hd'/>
  </os>
  <features>
    <acpi/>
    <apic/>
    <pae/>
  </features>
  <clock offset='utc'/>
  <on_poweroff>destroy</on_poweroff>
  <on_reboot>restart</on_reboot>
  <on_crash>restart</on_crash>
  <devices>
    <emulator>/usr/libexec/qemu-kvm</emulator>
    <disk type='file' device='disk'>
      <source file='/var/lib/libvirt/images/rhel5u5.img'/>
      <target dev='hda' bus='ide'/>
    </disk>
    <interface type='network'>
      <mac address='54:52:00:49:37:65'/>
      <source network='default'/>
    </interface>
    <serial type='pty'>
      <target port='0'/>
    </serial>
    <console type='pty'>
      <target port='0'/>
    </console>
    <input type='mouse' bus='ps2'/>
    <graphics type='vnc' port='-1' autoport='yes' keymap='en-us'/>
    <hostdev mode='subsystem' type='pci' managed='yes'>
      <source>
        <address domain='0x0000' bus='0x00' slot='0x19' function='0x0'/>
      </source>
    </hostdev>
  </devices>
</domain>

[root@dhcp-66-70-62 ~]# virsh start rhel5u5
Domain rhel5u5 started

[root@dhcp-66-70-62 ~]# readlink /sys/bus/pci/devices/0000\:00\:19.0/driver/ -f
/sys/bus/pci/drivers/pci-stub

[root@dhcp-66-70-62 ~]# ifconfig eth0
eth0: error fetching interface information: Device not found

[root@dhcp-66-70-62 ~]# virsh shutdown rhel5u5
Domain rhel5u5 is being shutdown

[root@dhcp-66-70-62 ~]# readlink /sys/bus/pci/devices/0000\:00\:19.0/driver/ -f
/sys/bus/pci/drivers/pci-stub

[root@dhcp-66-70-62 ~]# ifconfig eth0
eth0: error fetching interface information: Device not found

Note that,the host NIC will be available if we explicitly re-attach the NIC device:
[root@dhcp-66-70-62 ~]# virsh nodedev-reattach pci_8086_10bd
Device pci_8086_10bd re-attached

[root@dhcp-66-70-62 ~]# readlink /sys/bus/pci/devices/0000\:00\:19.0/driver/ -f
/sys/bus/pci/drivers/e1000e

[root@dhcp-66-70-62 ~]# ifconfig eth0
eth0      Link encap:Ethernet  HWaddr 00:23:AE:6F:F1:D7  
          inet addr:10.66.70.62  Bcast:10.66.70.255  Mask:255.255.255.0
          inet6 addr: fe80::223:aeff:fe6f:f1d7/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:1807 errors:0 dropped:0 overruns:0 frame:0
          TX packets:75 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:259894 (253.8 KiB)  TX bytes:20171 (19.6 KiB)
          Memory:febe0000-fec00000 

[root@dhcp-66-70-62 ~]# ping 10.66.70.161
PING 10.66.70.161 (10.66.70.161) 56(84) bytes of data.
64 bytes from 10.66.70.161: icmp_seq=1 ttl=64 time=0.616 ms
64 bytes from 10.66.70.161: icmp_seq=2 ttl=64 time=0.259 ms
......


Version-Release number of selected component (if applicable):
[root@dhcp-66-70-62 libvirt]# uname -a
Linux dhcp-66-70-62.nay.redhat.com 2.6.18-183.el5xen #1 SMP Mon Dec 21 18:46:14 EST 2009 x86_64 x86_64 x86_64 GNU/Linux
[root@dhcp-66-70-62 libvirt]# rpm -qa|grep libvirt
libvirt-debuginfo-0.6.3-23.el5
libvirt-0.6.3-23.el5
libvirt-python-0.6.3-23.el5
[root@dhcp-66-70-62 ~]# rpm -qa|grep kvm
kvm-tools-83-140.el5
kvm-qemu-img-83-140.el5
etherboot-zroms-kvm-5.4.4-13.el5
kvm-83-140.el5
etherboot-roms-kvm-5.4.4-13.el5
kmod-kvm-83-140.el5
[root@dhcp-66-70-62 ~]# lsmod|grep kvm
kvm_intel              86664  0 
kvm                   223648  2 ksm,kvm_intel
[root@dhcp-66-70-62 ~]#

(In reply to comment #5)
> This bug still exist with libvirt-0.6.3-23.el5 on rhel5u5,and it will raise
> different result if setting managed mode to 'yes' for xen and hypervisor:
> 
> 1.xen hypervisor
> The function can't be supported by the xen hypervisor,it will raise a error
> message:

OK, that part is expected; managed mode is not supported under Xen.  You always have to use unmanaged mode.  So we can ignore this part of the problem.

> 2.kvm hypervisor
> It can't still automatically re-attach the assigned device after guest be shut
> down,see following steps to reproduce:
> 
> [root@dhcp-66-70-62 ~]# virsh nodedev-list --tree
> computer
>   |
>   +-pci_8086_10bd
>   |   |
>   |   +-net_00_23_ae_6f_f1_d7
>   |
>   +-pci_8086_244e
>   +-pci_8086_2914
> ......
> 
> [root@dhcp-66-70-62 ~]# virsh nodedev-dumpxml pci_8086_10bd
> <device>
>   <name>pci_8086_10bd</name>
>   <parent>computer</parent>
>   <capability type='pci'>
>     <domain>0</domain>
>     <bus>0</bus>
>     <slot>25</slot>
>     <function>0</function>
>     <product id='0x10bd'>82566DM-2 Gigabit Network Connection</product>
>     <vendor id='0x8086'>Intel Corporation</vendor>
>   </capability>
> </device>
> 
> [root@dhcp-66-70-62 ~]# readlink /sys/bus/pci/devices/0000\:00\:19.0/driver/ -f
> /sys/bus/pci/drivers/e1000e
> 
> [root@dhcp-66-70-62 ~]# virsh edit rhel5u5
> Domain rhel5u5 XML configuration edited.
> 
> [root@dhcp-66-70-62 ~]# virsh dumpxml rhel5u5
> <domain type='qemu'>
>   <name>rhel5u5</name>
>   <uuid>c0e805d9-e288-e4e8-2357-13b39d57cb6e</uuid>
>   <memory>1048576</memory>
>   <currentMemory>1048576</currentMemory>
>   <vcpu>1</vcpu>
>   <os>
>     <type arch='x86_64' machine='pc'>hvm</type>
>     <boot dev='hd'/>
>   </os>
>   <features>
>     <acpi/>
>     <apic/>
>     <pae/>
>   </features>
>   <clock offset='utc'/>
>   <on_poweroff>destroy</on_poweroff>
>   <on_reboot>restart</on_reboot>
>   <on_crash>restart</on_crash>
>   <devices>
>     <emulator>/usr/libexec/qemu-kvm</emulator>
>     <disk type='file' device='disk'>
>       <source file='/var/lib/libvirt/images/rhel5u5.img'/>
>       <target dev='hda' bus='ide'/>
>     </disk>
>     <interface type='network'>
>       <mac address='54:52:00:49:37:65'/>
>       <source network='default'/>
>     </interface>
>     <serial type='pty'>
>       <target port='0'/>
>     </serial>
>     <console type='pty'>
>       <target port='0'/>
>     </console>
>     <input type='mouse' bus='ps2'/>
>     <graphics type='vnc' port='-1' autoport='yes' keymap='en-us'/>
>     <hostdev mode='subsystem' type='pci' managed='yes'>
>       <source>
>         <address domain='0x0000' bus='0x00' slot='0x19' function='0x0'/>
>       </source>
>     </hostdev>
>   </devices>
> </domain>
> 
> [root@dhcp-66-70-62 ~]# virsh start rhel5u5
> Domain rhel5u5 started
> 
> [root@dhcp-66-70-62 ~]# readlink /sys/bus/pci/devices/0000\:00\:19.0/driver/ -f
> /sys/bus/pci/drivers/pci-stub
> 
> [root@dhcp-66-70-62 ~]# ifconfig eth0
> eth0: error fetching interface information: Device not found
> 
> [root@dhcp-66-70-62 ~]# virsh shutdown rhel5u5
> Domain rhel5u5 is being shutdown

Actually, I run into a problem right here.  At the end of shutdown, libvirtd crashes on me with this stack trace:

#0  qemuCheckPciHostDevice (conn=0x0, owner_vm=0x17a75f60, dev=0x17a7a6d0)
    at qemu_driver.c:1233
#1  0x00002b4f28ec906d in pciResetDevice (conn=0x0, vm=0x17a75f60, 
    dev=0x17a7a6d0, check=0x41f6a0 <qemuCheckPciHostDevice>) at pci.c:647
#2  0x0000000000420b68 in qemuDomainReAttachHostDevices (
    vm=<value optimized out>, conn=<value optimized out>) at qemu_driver.c:1378
#3  qemudShutdownVMDaemon (vm=<value optimized out>, 
    conn=<value optimized out>) at qemu_driver.c:1711
#4  0x000000000042cd23 in qemudDispatchVMEvent (watch=10, fd=16, events=12, 
    opaque=<value optimized out>) at qemu_driver.c:1779
#5  0x000000000040e10f in virEventDispatchHandles (fds=<value optimized out>, 
    nfds=<value optimized out>) at event.c:451
#6  virEventRunOnce (fds=<value optimized out>, nfds=<value optimized out>)
    at event.c:578
#7  0x000000000040f478 in qemudOneLoop () at qemud.c:2079
#8  qemudRunLoop () at qemud.c:2184
#9  0x0000000000413981 in main (argc=396645872, argv=<value optimized out>)
    at qemud.c:2956

And looking at the code, it makes sense.  qemudShutdownVMDaemon() calls qemudDomainReAttachHostDevices() with a NULL conn parameter, but qemuCheckPciHostDevice() wants to dereference the conn parameter to get at the device list.  This causes the crash.  Upstream reverted the fix that's currently in RHEL-5 libvirt in favor of another way of doing this.  I'm going to attempt to backport the new code that upstream is using and see if that works better.

Chris Lalancette

Created attachment 382295 [details]
Upstream libvirt PCI hotplug code

This is the backport of the upstream code that I'm currently testing.  Mark, can you please give it a once over and make sure that it makes sense?

Thanks,
Chris Lalancette

Also, I've uploaded test packages here:

http://people.redhat.com/clalance/bz500217

Ajia, can you test out those packages and see if it works in your scenario?

Thanks,
Chris Lalancette

Hi,Chris,I has already installed these packages and retest it,but some error messages were raised:

[root@dhcp-66-70-62 ~]# virsh start rhel5u5_x86_64_qemu
error: Failed to start domain rhel5u5_x86_64_qemu
error: this function is not supported by the hypervisor: Failed to find parent device for 0000:00:19.0

and virt-manager also met a problem,"Device" drop list content is empty,although I reboot libvirtd service.the issue is resolved until I reboot host.

Created attachment 382409 [details]
steps to reproduce

(In reply to comment #9)
> Hi,Chris,I has already installed these packages and retest it,but some error
> messages were raised:
> 
> [root@dhcp-66-70-62 ~]# virsh start rhel5u5_x86_64_qemu
> error: Failed to start domain rhel5u5_x86_64_qemu
> error: this function is not supported by the hypervisor: Failed to find parent
> device for 0000:00:19.0

Hm, OK, odd.  I'm not seeing that on my machine, so there's probably something different.  Can you try some things for me:

1)  Start up libvirtd and virsh with more debugging.  In particular, do this:
    # service libvirtd stop
    # LIBVIRT_DEBUG=1 /usr/sbin/libvirtd --verbose
    <in another terminal>
    # LIBVIRT_DEBUG=1 virsh start rhel5u5_x86_64_qemu

    Then attach the output from both of those commands to this bug.

2)  Can you give me information so that I can access the machine you are working with?  If I can work directly on that machine, I can probably solve it a bit faster.

Thanks,
Chris Lalancette

(In reply to comment #11)
> (In reply to comment #9)
> > Hi,Chris,I has already installed these packages and retest it,but some error
> > messages were raised:
> > 
> > [root@dhcp-66-70-62 ~]# virsh start rhel5u5_x86_64_qemu
> > error: Failed to start domain rhel5u5_x86_64_qemu
> > error: this function is not supported by the hypervisor: Failed to find parent
> > device for 0000:00:19.0
> 
> Hm, OK, odd.  I'm not seeing that on my machine, so there's probably something
> different.  Can you try some things for me:
> 
> 1)  Start up libvirtd and virsh with more debugging.  In particular, do this:
>     # service libvirtd stop
>     # LIBVIRT_DEBUG=1 /usr/sbin/libvirtd --verbose
>     <in another terminal>
>     # LIBVIRT_DEBUG=1 virsh start rhel5u5_x86_64_qemu
> 
>     Then attach the output from both of those commands to this bug.
Hi,Chris,I retest it according the above steps,but guest define be destroyed oddly,and output information is too long,so I haven't added it as a attachment instead of providing my machine with you,and I will always keep the machine running,so that you can log on it at any time. 
> 
> 2)  Can you give me information so that I can access the machine you are
> working with?  If I can work directly on that machine, I can probably solve it
> a bit faster.
> 
> Thanks,
> Chris Lalancette   

Chris,not at all,I will provide my test environment with you,so that you can solve the issue quickly.please check you email for the login information.

OK.  I went through this issue with Don Dutile, and after explaining to him the problem I've been having along with showing him the data sheet for this particular machine (Dell Optiplex 755) he told me that this particular platform does *not* support PCI passthrough.  That is, the BIOS has fake DMAR tables that don't actually work, and therefore when trying to do the PCI passthrough I get the crashes that I'm seeing.

Alex, are you sure that PCI passthrough has ever worked?  It seems like it won't work with this BIOS/chipset, which would explain all of the problems I've been having trying to reproduce the issue on your machine.

If you are sure it has worked, then I absolutely need for you to setup a serial console attached to that machine so I can figure out why it is crashing.  I cannot make progress otherwise.

Chris Lalancette

I am not sure PCI passthrough has ever worked,but the Dell Optiplex 755 should support the feature,because the machine with VT-d support and I enable the option in BIOS,meanwhile I also add intel_iommu=on parameter option into kernel cmd,but the same error is still raised:
[root@dhcp-66-70-62 ~]# virsh start rhel5u5_x86_64_kvm
error: Failed to start domain rhel5u5_x86_64_kvm
error: this function is not supported by the hypervisor: Failed to find parent device for 0000:00:19.0


additional information:
[root@dhcp-66-70-62 ~]# uname -a
Linux dhcp-66-70-62.nay.redhat.com 2.6.18-185.el5 #1 SMP Thu Jan 14 16:44:40 EST 2010 x86_64 x86_64 x86_64 GNU/Linux

[root@dhcp-66-70-62 ~]# lsmod|grep kvm
kvm_intel              86664  0 
kvm                   223648  2 ksm,kvm_intel

[root@dhcp-66-70-62 ~]# rpm -qa|grep libvirt
libvirt-python-0.6.3-29.el5bz500217
libvirt-0.6.3-29.el5bz500217

[root@dhcp-66-70-62 ~]# dmesg|grep -i iommu
Command line: ro root=LABEL=/ intel_iommu=on
Kernel command line: ro root=LABEL=/ intel_iommu=on
Intel-IOMMU: enabled
IOMMU fedae000: ver 1:0 cap c9008020a30270 ecap 1000
IOMMU fedb0000: ver 1:0 cap c0000020230270 ecap 1000
IOMMU fedb1000: ver 1:0 cap c9008020230270 ecap 1000
IOMMU 0xfedb0000: using Register based invalidation
IOMMU 0xfedae000: using Register based invalidation
IOMMU 0xfedb1000: using Register based invalidation
IOMMU: Setting RMRR:
IOMMU: Setting identity map for device 0000:00:1d.0 [0xbfe58000 - 0xbfe70000]
IOMMU: Setting identity map for device 0000:00:1d.1 [0xbfe58000 - 0xbfe70000]
IOMMU: Setting identity map for device 0000:00:1d.2 [0xbfe58000 - 0xbfe70000]
IOMMU: Setting identity map for device 0000:00:1d.7 [0xbfe58000 - 0xbfe70000]
IOMMU: Setting identity map for device 0000:00:1a.0 [0xbfe58000 - 0xbfe70000]
IOMMU: Setting identity map for device 0000:00:1a.1 [0xbfe58000 - 0xbfe70000]
IOMMU: Setting identity map for device 0000:00:1a.7 [0xbfe58000 - 0xbfe70000]
IOMMU: Prepare 0-16MiB unity mapping for LPC
IOMMU: Setting identity map for device 0000:00:1f.0 [0x0 - 0x1000000]

[root@dhcp-66-70-62 ~]# cat /boot/grub/grub.conf |grep iommu
        kernel /boot/vmlinuz-2.6.18-185.el5 ro root=LABEL=/ intel_iommu=on
        kernel /boot/vmlinuz-2.6.18-183.el5 ro root=LABEL=/ rhgb quiet intel_iommu=on

(In reply to comment #13)
> OK.  I went through this issue with Don Dutile, and after explaining to him the
> problem I've been having along with showing him the data sheet for this
> particular machine (Dell Optiplex 755) he told me that this particular platform
> does *not* support PCI passthrough.  That is, the BIOS has fake DMAR tables
> that don't actually work, and therefore when trying to do the PCI passthrough I
> get the crashes that I'm seeing.
> 
> Alex, are you sure that PCI passthrough has ever worked?  It seems like it
> won't work with this BIOS/chipset, which would explain all of the problems I've
> been having trying to reproduce the issue on your machine.
> 
> If you are sure it has worked, then I absolutely need for you to setup a serial
> console attached to that machine so I can figure out why it is crashing.  I
> cannot make progress otherwise.
> 
> Chris Lalancette    

Hi,Chris,the PCI passthrough will work if we degrade libvirt version to 0.6.3-23.el5(please refer to bug 517465).

There are some problems at present:
1.libvirt-0.6.3-23.el5 can pci passthrough,but when the guest is shutdown,the assigned device can't be re-attach automatically.

2.but pci passthrough can't succeed on libvirt-0.6.3-29.el5/alibvirt-0.6.3-30.el5, this may be a regression bug,which blocks me to continue to verify the current bug,so I am not sure the assigned device if can be re-attach automatically.

(please see the attachment information)

Created attachment 384894 [details]
libvirt-0.6.3-23.el5

Created attachment 384895 [details]
libvirt-0.6.3-30.el5

My machine chipset is "Intel Q35 Express Chipset",it does have VT-d support and I pass through NICs successfully with libvirt-0.6.3-23.el5 on rhel5u5.

[root@dhcp-66-70-62 ~]# lspci
00:00.0 Host bridge: Intel Corporation 82Q35 Express DRAM Controller (rev 02)
00:01.0 PCI bridge: Intel Corporation 82Q35 Express PCI Express Root Port (rev 02)
00:03.0 Communication controller: Intel Corporation 82Q35 Express MEI Controller (rev 02)
00:03.2 IDE interface: Intel Corporation 82Q35 Express PT IDER Controller (rev 02)
00:03.3 Serial controller: Intel Corporation 82Q35 Express Serial KT Controller (rev 02)
00:19.0 Ethernet controller: Intel Corporation 82566DM-2 Gigabit Network Connection (rev 02)
00:1a.0 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #4 (rev 02)
00:1a.1 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #5 (rev 02)
00:1a.7 USB Controller: Intel Corporation 82801I (ICH9 Family) USB2 EHCI Controller #2 (rev 02)
00:1b.0 Audio device: Intel Corporation 82801I (ICH9 Family) HD Audio Controller (rev 02)
00:1c.0 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express Port 1 (rev 02)
00:1d.0 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #1 (rev 02)
00:1d.1 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #2 (rev 02)
00:1d.2 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #3 (rev 02)
00:1d.7 USB Controller: Intel Corporation 82801I (ICH9 Family) USB2 EHCI Controller #1 (rev 02)
00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev 92)
00:1f.0 ISA bridge: Intel Corporation 82801IO (ICH9DO) LPC Interface Controller (rev 02)
00:1f.2 SATA controller: Intel Corporation 82801IR/IO/IH (ICH9R/DO/DH) 6 port SATA AHCI Controller (rev 02)
00:1f.3 SMBus: Intel Corporation 82801I (ICH9 Family) SMBus Controller (rev 02)
01:00.0 VGA compatible controller: ATI Technologies Inc RV610 video device [Radeon HD 2400 PRO]

I will change another HPz800 machine to verify the issue again.

Alex,
     I've found out quite a few new things today.  Let me tell you what I've found:

1)  You are right, that Dell Optiplex 755 *does* support device passthrough.  So that is a fine box to continue testing with.
2)  The reason that I kept seeing the box "crash" when I tried to test out your steps is that you were assigning the one and only NIC to the guest.  While that's a fine test for you to do locally, it doesn't work over ssh :).
3)  There was a bug in the libvirt code, not related to my latest patch, that was causing your issues.  I've put together another patch to fix that bug now.

So, with that being said, please download the new packages from:

http://people.redhat.com/clalance/bz500217

And install them on the Dell Optiplex 755.  Don't forget to do "service libvirtd restart" or reboot the machine after you have installed them.  Once they are installed, please repeat your steps from Comment #5 and see if it works for you.

Thanks,
Chris Lalancette

Hi,Chris,I retest it with libvirt-0.6.3-30.el5bz500217.x86_64 on Dell Optiplex 755 machine,and the NICs passthrough is successful,but the assigned NICs can't re-attach automatically after guest shutdown.I think libvirt haven't checked domain "managed" mode when the guest is shutdown.so libvirt also haven't called qemudNodeDeviceReAttach and qemudNodeDeviceReset functions return the device to host.please refer to attachment.

Alex

Hi,Chris,I retest it with libvirt-0.6.3-30.el5bz500217.x86_64 on Dell Optiplex 755 machine,and the NICs passthrough is successful,but the assigned NICs can't re-attach automatically after guest shutdown.I think libvirt haven't checked domain "managed" mode when the guest is shutdown.so libvirt also haven't called qemudNodeDeviceReAttach and qemudNodeDeviceReset functions return the device to host.please refer to attachment.

Alex

Hi,Chris,I retest it with libvirt-0.6.3-30.el5bz500217.x86_64 on Dell Optiplex 755 machine,and the NICs passthrough is successful,but the assigned NICs can't re-attach automatically after guest shutdown.I think libvirt haven't checked domain "managed" mode when the guest is shutdown.so libvirt also haven't called qemudNodeDeviceReAttach and qemudNodeDeviceReset functions return the device to host.please refer to attachment.

Alex

Created attachment 385597 [details]
the detail

Alex,
     Thanks for the additional testing.  I'd like to ask you to do two things:

1)  Re-run the test exactly as you did in Comment #23.  When you reach the end of the test, collect the output from "dmesg" and attach it to this bug.

2)  Once you've done step 1), I have another test package for you to try out.  This one is at:

http://people.redhat.com/clalance/bz500217v2

Please download those packages, install them on your test machine, restart libvirtd, and then re-run the test in Comment #23 again.

Thanks,
Chris Lalancette

Chris,I retest it with libvirt-0.6.3-30.el5bz500217v2.x86_64 on Dell Optiplex
755 machine,everything is ok,the assigned NICs also can re-attach automatically after guest shutdown.if no question,I will set the bug status to VERIFIED via errata.

Created attachment 385866 [details]
dmesg information

Created attachment 385868 [details]
verified information

(In reply to comment #25)
> Chris,I retest it with libvirt-0.6.3-30.el5bz500217v2.x86_64 on Dell Optiplex
> 755 machine,everything is ok,the assigned NICs also can re-attach automatically
> after guest shutdown.if no question,I will set the bug status to VERIFIED via
> errata.    

No, we can't set it to VERIFIED yet; the patches I have in here are proposed, and not yet built into the official package.  I'm going to be posting the patches for review and discussion today, and then hopefully we can get it into RHEL-5 soon.

Chris Lalancette

Chris,I know and I will wait for libvirt respin and retest it.

Alex Jia

*** Bug 558779 has been marked as a duplicate of this bug. ***

Fix built in libvirt-0.6.3-31.el5

This bug has been fixed with libvirt-0.6.3-31.el5 on rhel5u5,set the bug status to VERIFIED.(see the attachment)

Created attachment 387476 [details]
details

An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2010-0205.html