On Tue, Apr 18, 2006 at 09:16:19PM -0400, Bret McMillan wrote: > On Tue, 2006-04-18 at 17:40 -0400, Daniel Veillard wrote: > > On Tue, Apr 18, 2006 at 04:40:13PM -0400, Daniel Veillard wrote: > > /* define a domain, but does not start it */ > > virDomainPtr virDomainDefineXML(virConnectPtr conn, const char *xml); > > /* undefine a domain but does not stop it if running */ > > int virDomainUndefine(virDomainPtr domain); > > /* list the defined domains */ > > int virConnectListDefinedDomains(virConnectPtr conn, const char **names, > > int maxnames); > > /* launch a defined domain */ > > int virDomainCreate(virDomainPtr domain); > > > > extensions to the current behaviour: > > > > - new state for defined non-running domains showing in virNodeGetInfo > > - virDomainLookupByName() could return a defined non-running domain > > - virDomainCreateLinux() would fail if a domain with the same name is > > already defined > > - a number of existing APIs would fail on defined but non-running domains. > > > > that's it. > > Daniel, > > Thanks for the summary, I think it makes it a good bit clearer about > what folks are shooting for. Just a couple of questions for the folks > thinking about using this state: > > 1) What state, local to the physical hardware, will be altered by calls > to virDomainDefineXML? Just xenstore? Or would this stuff bleed over > into configfiles getting dropped onto disk? Or is that simply up to the > management app calling into libvirt? IMHO, this could mean absolutely no state change on the managed machine, libvirt could very well talk only to the remote node though just xend, libvirt would have those informations in memory, and even the remote xenstore could not be affected at all. Another situation could be a local tool run by the user where the configuration is pulled by the application from say $HOME/xen and configs are written to xenstore. For the CIM model feedback from an expert would be welcome :-) > 2) Do we expect other local tools to adopt this notion of state? Or > will this only live in libvirt-based code? If you mean do we expect xm to be extended for this, this seems unlikely as xm is really based on the /etc/xen/ directory and libvirt precisely try to avoid dependancy on any such local database, I don't expect both set of use to be joined in general, but I may be wrong. If you start creating your domains with libvirt, well you won't have an entry in /etc/xen unless you really like to store your data in python scripts which I guess is not very common. Daniel -- Daniel Veillard | Red Hat http://redhat.com/ veillard@xxxxxxxxxx | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/