[libvirt] [PATCH] qemu: Check for ejected media during startup and migration
eblake at redhat.com
Fri Sep 16 15:38:45 UTC 2011
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
Eric Blake eblake at redhat.com +1-801-349-2682
Libvirt virtualization library http://libvirt.org
More information about the libvir-list