[Libvir] Request for additional entry points

Karel Zak kzak at redhat.com
Wed Apr 19 07:33:49 UTC 2006

On Tue, Apr 18, 2006 at 05:43:35PM -0700, David Lutterkort 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:
> >   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

 The solution with xm-based tools and Python based config files is
 pretty closed for future extensions and GUI applications. I hope it
 will be replaced with tools based on libvirt which is based on C 
 (=possible bindings to others langs) and XML (=common standard). 

> into the CIM model of managing configurations, it seems very non-Unixy

 gconf <-- ? 

> to have API's for something that amounts to simple file management
> tasks.

 The API is a way how inform all system tools about your inactive
 domains. There still will be possible use files and start up new
 domains by "virsh create /path/dom.conf".

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

 Everywhere. The API is a way how register your configuration to the
 I think the question is if we need this libvirt low-level solution or
 we can alive only with some non-libvirt high-level (dbus) solution or
 we should support both solutions in our tools.

> 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

 No second. It's replacement. We don't want to coexist with xm Python
 config files and libvirt XML definitions in one system.

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

 Karel Zak  <kzak at redhat.com>

More information about the libvir-list mailing list