Re: device removal

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list




[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]