Re: [libvirt] device removal
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.
Michal