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 -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list