[Libvir] Request for additional entry points

[Bret McMillan]

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:
> >   So we have 2 more APIs which allows to define the XML for a domain
> > and name it. That then allow to reserve that name, and the domain may be started
> > later with a simpler API.
> 
> Since I have troubles understanding why you have such an issue with this,
> let's try to be as clear as possible. What I would expect is the following
> APIs to be added:
> 
> /* 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?

--Bret