[libvirt] device removal

[Serge Hallyn]

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.

-serge