Re: [libvirt] xen driver & events
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.
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 :|