[libvirt] xen driver & events

Daniel P. Berrange berrange at redhat.com
Tue Oct 28 18:10:11 UTC 2008

On Tue, Oct 28, 2008 at 02:00:48PM -0400, Ben Guthro wrote:
> I'm looking into implementing emitting events from the xen driver, and 
> I've run into a bit of a snag that I would like to discuss
> I've attached an old version of my patch for reference.
> However - from past discussions, I know that there was a desire to keep
> the xen driver stateless. However, given the semantics of xenstore 
> watches, and events, I'm not sure I can see a way to preserve this.
> Lets take the case of creating a new domain:
> XenStore gives us the functionaliity to put a watch on the special 
> xenstore key @introduceDomain.
> However, when the watch fires - I see no mechanism of determining which
> domain has been introduced. 

Indeed - looking at the code in xen which fires this event, I see no
way to determine which is the new/old domain. 

> The only mechanism I can find is to maintain a list of domains, and 
> keep this up to date with events.
> So I'm wondering if anyone has any ideas, or if this will introduce 
> unwanted, but necessary state into the driver?

This does appear to be the only option, it doesn't mean that we need to make
Xen a fully stateful driver like QEMU. All this really amounts to is tracking
a list of integer IDs or UUIDs - this is small enough that we can just keep
track of it in the 'struct _xenUnifiedPrivate' which is per-virConnectPtr
instance. When we get a introduceDomain watch, we'd just need to re-query
for the list of IDs and compare to figure out what's new/old. We only need
do this tracking if we've got a domain event callback registered, so I
think this is acceptable.

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

More information about the libvir-list mailing list