[libvirt] [PATCH] qemu: Check for ejected media during startup and migration

[Eric Blake]

On 09/14/2011 01:52 AM, Michal Privoznik wrote:
> On 14.09.2011 01:05, Eric Blake wrote:
>> On 09/13/2011 05:03 PM, Eric Blake wrote:
>>> On 09/13/2011 10:14 AM, Michal Privoznik wrote:
>>>> If the daemon is restarted so we reconnect to monitor, cdrom media
>>>> can be ejected. In that case we don't want to show it in domain xml,
>>>> or require it on migration destination.
>>>>
>>>> To check for disk status use 'info block' monitor command.
>>>
>>> Yuck - this is still polling-based (we have to ask qemu every time we
>>> want to dumpxml). Whatever happened to the proposal of having
>>> interrupt-based cdrom events, where qemu sends an event any time the
>>> virtual tray changes state (whether by monitor command or
>>> guest-initiated), and libvirt monitors those events to update its
>>> internal state at that time, so that libvirt's internal state is always
>>> accurate?
>>
>> For reference:
>> https://www.redhat.com/archives/libvir-list/2011-August/msg00487.html
>>
> My patch does not touch dumpxml. It access monitor only on process
> reconnect and in early migration phase. In both cases we access monitor
> anyway.

That is, you are polling the status at any location where you would be 
doing an internal dumpxml.  So while this is not exposing things to the 
user (and thus less polling), it is still doing polling.  I'm also 
worried about virDomainSave and virDomainSnapshotCreateXML needing to be 
hooked into doing these sorts of polling, to work correctly.

I'd feel much better revisiting this issue post-0.9.5 - it's too 
invasive to fix right now.

> But I agree that events would be nicer, but I don't think they are gonna
> be implemented in near future. However, even if they would have been
> implemented now, we need to check the tray during process reconnect.

You have a point there - but that is a one-time poll, rather than on 
every operation that needs to preserve xml state.

> Because if the libvirtd was down and during this time guest ejected
> cdrom and qemu sent event, we would not catch it - because we are not
> running. So in order to keep things consistent, we must check tray
> during startup.
> Migration is the same. Even if qemu will sent events at one time, we
> still need to check if we are talking to older qemu.

This should be capability-based - we should know whether the qemu we are 
talking to supports nothing (0.14), polling (is it in qemu yet? or still 
just pending), or events (even further down the road), and make 
appropriate decisions on how much to probe according to the qemu we are 
talking to.

-- 
Eric Blake   eblake at redhat.com    +1-801-349-2682
Libvirt virtualization library http://libvirt.org