On Tue, Nov 04, 2008 at 03:31:56PM -0500, Ben Guthro wrote: > > > Daniel P. Berrange wrote on 11/04/2008 02:56 PM: > > A couple more things I've not fixed but are on the todo list > > > > - THe QEMU driver doesn't emit the ADDED or REMOVED events for VMs > > which virt-manager requires in order to fully avoid polling. > > Not to derail this topic from your patch...but this comment somewhat > relates to the xen driver changes I've been looking at. > > Currently, I can detect domains being externally created, and destroyed > via a xenstore watch. > > That said - there is no mechanism like @introduceDomain/@releaseDomain > for the rest of domain lifecycle events. As far as I can tell, these > control events such as pause/resume, etc are controlled via the xen > control(xc) library. I saw nothing in this library, or the xend python > code that would indicate that anything is written in xenstore. > > So - I can look into plumbing up the rest of the events in the driver > without this. This would mean that it could emit events when issued by > libvirt, but would only issue STARTED, and STOPPED events from external > influences like 'xm' Hmm, nothing is ever as simple as it first seems in the Xen world :-) So, first off all there are two possible backends for libvirt Xen - Old Xen < 3.0.4. The 'xm_internal.c' file manages /etc/xen config files for inactive VMs directly - New Xen >= 3.0.4. The 'xend_internal.c' file use Xen SEXPR API for managing inactive VMs. XenD indirectly stuffs them into the directory /var/lib/xend/domains/ In both cases we can only figure out STARTED/STOPPED from hypervisor & xenstored events. In the first case, we could use inotify to get notication of files in /etc/xen being added/removed and thus do the ADDED/REMOVED events. We could actually also use inotify on /var/lib/xend/domains/ though that feels a little more evil since that's a private directory to XenD. This still doesn't give us any pause/resume/save/restore events. The latter two would just in fact show up as STARTED/STOPPED events. Then there is XenAPI in Xen >= 3.1.0. We don't currently use XenAPI at all, and I'm not up2date on its level of functionality, but in the original scope it was intended to provide full event notification capabilities for VMs. If the XenAPI event stuff was ever implemented, then perhaps we should make use of that, and say older non-XenAPI versions only get a limited sub-set of our events ? Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| -- Libvir-list mailing list Libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list