Description of problem: Libvirt should report failure when detach hostdev unsuccessfully. Version-Release number of selected component (if applicable): libvirt-1.1.1-2.el7.x86_64 qemu-kvm-1.5.2-1.el7.x86_64 kernel-3.10.0-3.el7.x86_64 How reproducible: 100% Steps: 1. Define a guest with the following hostdev device <hostdev mode='subsystem' type='pci' managed='yes'> <source> <address domain='0x0000' bus='0x01' slot='0x00' function='0x0'/> </source> </hostdev> 2. Execute 2.1 and 2.2 at the same time. 2.1 Start the guest. [root@SRIOV2 ~]# virsh start r7_g Domain r7_g started [root@SRIOV2 ~]# virsh list --all Id Name State ---------------------------------------------------- 7 r7_g running 2.2 In another terminal,execute below command immediately: [root@SRIOV2 ~]# virsh detach-device r7_g hostdev.xml Device detached successfully <======= this is issue. 3. Dumpxml domain xml. [root@SRIOV2 ~]# virsh dumpxml r7_g | grep -A10 hostdev <hostdev mode='subsystem' type='pci' managed='yes'> <source> <address domain='0x0000' bus='0x01' slot='0x00' function='0x0'/> </source> <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/> </hostdev> [root@SRIOV2 ~]# virsh dumpxml r7_g --inactive| grep -A10 hostdev <hostdev mode='subsystem' type='pci' managed='yes'> <source> <address domain='0x0000' bus='0x01' slot='0x00' function='0x0'/> </source> <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/> </hostdev> 4. In guest, to check the nic status, it's in the domain. [root@test005 ~]# lspci| grep Eth 00:03.0 Ethernet controller: Intel Corporation 82574L Gigabit Network Connection [root@test005 ~]# ifconfig eth1 eth1 Link encap:Ethernet HWaddr B4:B5:2F:AF:A1:00 inet addr:10.66.71.177 Bcast:10.66.71.255 Mask:255.255.254.0 inet6 addr: fe80::b6b5:2fff:feaf:a100/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:16 errors:0 dropped:0 overruns:0 frame:0 TX packets:10 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:1932 (1.8 KiB) TX bytes:1588 (1.5 KiB) Interrupt:11 Memory:fc000000-fc020000 [root@test005 ~]# ping 10.66.7.130 PING 10.66.7.130 (10.66.7.130) 56(84) bytes of data. 64 bytes from 10.66.7.130: icmp_seq=1 ttl=62 time=0.324 ms 64 bytes from 10.66.7.130: icmp_seq=2 ttl=62 time=0.282 ms 64 bytes from 10.66.7.130: icmp_seq=3 ttl=62 time=0.402 ms --- 10.66.7.130 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2391ms rtt min/avg/max/mdev = 0.282/0.336/0.402/0.049 ms [root@test005 ~]# Actual results: As step 2.2 shown. Expected results: Libvirt should report an error if detach device fail.
This bug should be tracked in rhel6, cloned it. Bug 1133443 - Libvirt should report failure when detach hostdev unsuccessfully.
*** Bug 1255287 has been marked as a duplicate of this bug. ***
Well, the only fix (if it appears to be reasonably doable) for this is going to be in virsh so that it doesn't print the misleading "device successfully detached" message when the API returns 0. In other words, if any application using libvirt relies on virDomainDetachDevice to return zero only if the device was actually removed, the application itself needs to be fixed because it never worked like that (although it wasn't explicitly documented). Ideally, the application should listen for a device detach event which is triggered when device removal is finished (which may happen before virDomainDetachDevice returns but it may also be send later or never). It's also possible to dump domain XML and check if the device is still there.
*** Bug 1258312 has been marked as a duplicate of this bug. ***
The problem seems to be not on the libvirt
*** Bug 1456039 has been marked as a duplicate of this bug. ***
Thank you for reporting this issue to the libvirt project. Unfortunately we have been unable to resolve this issue due to insufficient maintainer capacity and it will now be closed. This is not a reflection on the possible validity of the issue, merely the lack of resources to investigate and address it, for which we apologise. If you none the less feel the issue is still important, you may choose to report it again at the new project issue tracker https://gitlab.com/libvirt/libvirt/-/issues The project also welcomes contribution from anyone who believes they can provide a solution.