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

[Michal Privoznik]

On 16.09.2011 17:38, Eric Blake wrote:
> 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.
> 

So I think the conclusion is: we need both, extended 'info block' (to do
one-time poll on startup) and events (any later on).

And I agree with that. However, qemu implements only the first part -
extended 'info block' command so far. As soon as it will implement
events too, we can adapt to them => make the check in migration early
phase dependent on qemu capabilities. But I think the current patch is
the best we can do right now.

Michal