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

I reviewed the patch, looks fine, having xendConfigVersion attached to the conn actually cleans up the code as a result, even better !