Re: Request for additional entry points

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

 



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. Now what is fundamentally wrong with that ? You don't have to
> use it if you don't need it I assume the problem is harder than this.

What I don't understand is why these API's are needed at all - with the
xm-based tools you can do all these things very easily from the command
line without any need to pull in extra libraries. While it fits well
into the CIM model of managing configurations, it seems very non-Unixy
to have API's for something that amounts to simple file management
tasks.

What is the interplay between these API calls and storing config files
in the local file system ? Where am I supposed to look to find all
inactive domains on a system ? libvirt ? /etc/xen ? Somewhere else
in /etc ? If I want to define an inactive domain on a system, where
should I put the XML description ?

I think there is a much harder question concerning the interplay of
libvirt and the xm tools that this API discussion is somewhat
sidestepping. Currently, the xm tools set a defacto standard for how you
define inactive domains; libvirt will add a second mechanism with the
proposed API. And since the libvirt XML descriptions are a much nicer
way to describe a domain than the python scripts in /etc/xen, there's a
big temptation to write libvirt based tools that use the XML description
and replicate (some) of the xm functionality. That would give us three
separate ways to define an inactive domain on a local system - madness
ensues.

I would be very curious to hear how people see how the libvirt XML
descriptions and xm or libvirt-based xm-like tools would interact.

David




[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]