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@xxxxxxxxxx +1-801-349-2682
Libvirt virtualization library http://libvirt.org
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list