[libvirt] device removal
serge.hallyn at ubuntu.com
Mon Jan 6 18:35:39 UTC 2014
Quoting Michal Privoznik (mprivozn at redhat.com):
> 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 at 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
So even if the event is received while we're still waiting, it will have
been received and handled by another thread so we don't have to? That
explains handling 1 and 2 return value the same way then, thanks :)
> qemu doesn't support the event). All other return values are irrelevant
> to us in the current context.
Thanks very much. I'll update the testcase then.
> BTW: device removal may require guest kernel cooperation (e.g. when
> detaching a PCI device) - hence it may take ages to complete.
More information about the libvir-list