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
system.
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
--
Karel Zak <kzak@xxxxxxxxxx>