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

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

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

For reference:

My patch does not touch dumpxml. It access monitor only on process
reconnect and in early migration phase. In both cases we access monitor

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 redhat com    +1-801-349-2682
Libvirt virtualization library http://libvirt.org

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