On 03.01.2014 05:38, Serge Hallyn wrote: > Hi, > > one of our tests was complaining that after an attach-device > followed by detach-device, the device was still in the vm's > apparmor whitelist. It turns out the device actually also > still in the device's xml. qemuDomainDetachVirtioDiskDevice() > is calling > > if (!qemuDomainWaitForDeviceRemoval(vm)) > qemuDomainRemoveDiskDevice(driver, vm, detach); > ret = 0; > > Return values for qemuDomainWaitForDeviceRemoval are: > > * -1 on error > * 0 when DEVICE_DELETED event is unsupported > * 1 when device removal finished > * 2 device removal did not finish in QEMU_REMOVAL_WAIT_TIME > > Those don't seem in line with how the return value is used. (According > to gdb, it is returning 2 in my case.) I don't understand how the async > device removal proceeds, but if qemuDomainWaitForDeviceRemoval() > returned an error (-1 or 2) should qemuDomainDetachVirtioDiskDevice() at > least return an error, assuming it's not safe to call > qemuDomainRemoveDiskDevice()? > > As it is, I get > > # serge@t1:~/qa-regression-testing/scripts$ virsh detach-device qatest-i386 /tmp/tmpivE45x/device.xml > # Device detached successfully > > but the device is actually still in qatest-i386's xml. Seems like the > caller should be informed that the device is still attached. Assuming > I'm not completely mis-reading the situation. > No, you're on the right track. Although, historically the Detach* APIs were 'issue the request to the hypervisor' rather than 'issue the request and wait for device to detach' (limiting myself to QEMU here). Users had to check the XML then whether/then the device was really removed. But just recently (since 1.1.1) we've modified the behaviour a bit. In one thread we're issuing the detach request and (possibly) waiting for qemu to detach the device in 5 secs (qemuDomainRemoveDeviceWaitTime). Then, the event loop listens for events on the monitor and whenever the DETACH event comes, the internal domain definition is adjusted. This approach, however, requires qemu to be able to send the DETACH event. So whenever qemu doesn't support the event, we remove the device from XML straight away. In all other cases, the device is removed upon event delivery. Hence, the only return value we care about is 0 (meaning

qemu doesn't support the event). All other return values are irrelevant to us in the current context.

BTW: device removal may require guest kernel cooperation (e.g. when detaching a PCI device) - hence it may take ages to complete.