Re: [PATCH] Inactive domain management for Xen 3.0.4

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]