[Libvir] [PATCH] Inactive domain management for Xen 3.0.4
Daniel P. Berrange
berrange at redhat.com
Wed Dec 13 22:21:39 UTC 2006
On Wed, Dec 13, 2006 at 05:04:27PM -0500, Daniel Veillard wrote:
> On Wed, Dec 13, 2006 at 08:32:13PM +0000, Daniel P. Berrange wrote:
> > So, my previous set of patches for inactive domain management deal with the
> > problem for Xen 3.0.3 or earlier. In 3.0.4 we now have lifecycle management
> > support, which means we no longer need to scan /etc/xen config files if
> > running against a new XenD. We choose between Xend & scanning /etc/xen
> > files based on the condition 'xendConfigVersion >= 3'.
> >
> > The attached patch adds 5 new entry points to xend_internal.c
> >
> > xenDaemonListDefinedDomains
> > xenDaemonNumOfDefinedDomains
> > xenDaemonDomainCreate
> > xenDaemonDomainDefineXML
> > xenDaemonDomainUndefine
> >
> > These let you enumerate inactive domains, define new ones, delete old ones.
> >
> > Secondly, the patch modifies a number of existing methods to work against
> > inactive domains too. Previously they'd unconditionally pass if the
> > domain id was < 0. Now, if xendConfigVersion is >= 3, then they will
> > know that XenD supports inactive domains & thus work for inactive guests
> > too.
> >
> > xenDaemonDomainGetMaxMemory
> > xenDaemonDomainSetMaxMemory
> > xenDaemonDomainSetMemory
> > xenDaemonDomainGetInfo
> > xenDaemonDomainSetVcpus
> > xenDaemonDomainDumpXML
> >
> > The methods for setting mem,max memory & vcpu count all required further
> > bug fixes to Xend which have been sent upstream & hopefully merged soon.
>
> okay this all makes sense.
>
> > Finally, the patch changes the xendConfigVersion to be lookedup just once
> > when initially connecting to XenD. Since we need this version info very
> > frequently now, it was causing too much unnneccessary overload calling
> > it every time.
>
> Hum, let's see if xend is stopped, upgraded and restarted the connections
> would be lost and recreated, so this should be just fine. It just reminds me
> that we didn't tested much libvirt behaviour in case of stop/start of xend,
> but it's not easy to provide in regression tests...
Empirically, it 'just works'. I have Karel's gnome-applet-vm running on my
dsktop all the time. I can stop Xend - it notices & turns red; I start Xend
and it starts working again. The same also works fine with virt-manager. So
as long as applications deal with failures to the various APIs gracefully,
there's no problem restarting XenD. Certainly no need to re-open the libvirt
connection object.
> I reviewed the patch, looks fine, having xendConfigVersion attached to
> the conn actually cleans up the code as a result, even better !
Ok, will commit it.
Dan
--
|=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=|
|=- Perl modules: http://search.cpan.org/~danberr/ -=|
|=- Projects: http://freshmeat.net/~danielpb/ -=|
|=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|
More information about the libvir-list
mailing list