[libvirt] PATCH: Misc fixes to events code

[Daniel P. Berrange]

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 :|