Re: [Libvir] Request for additional entry points

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?

2) Do we expect other local tools to adopt this notion of state? Or will this only live in libvirt-based code?