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@redhat.com>