On Sun, Aug 10, 2008 at 02:28:27AM +0100, Jamie Lokier wrote: > Javier Guerra wrote: > > On Thu, Aug 7, 2008 at 8:06 AM, Richard W.M. Jones <rjones@xxxxxxxxxx> wrote: > > > I think the message here is, install libvirt & be happy :-) > > > > nice as this tool sounds, i would need far more than this to make me > > switch from a simple, easily scriptable command-line to a generic, > > 'lowest common', solution like libvirt. > > > > of course, i hope it keeps getting better. who knows? maybe in a year > > or so it would be comparable to the CLI. > > Regrettably I agree for the moment. > > I ended up writing a Perl management script for my KVM VMs because > libvirt was just too muddled and limited for my needs, and because the > config file format confused me, didn't handle everything I needed, and > I didn't find clear documentation on it. The configuration format is documented here: http://libvirt.org/formatdomain.html You can also print out the configuration from any existing guest using 'virsh dumpxml <domain>' if you need examples. I'm intrigued by what your Perl management script needed that isn't exposed by libvirt. Libvirt deliberately doesn't expose the full feature set of any one hypervisor which it supports, but instead exposes common features. The reason for this is so that you can switch hypervisor technologies later on. Clearly, we all love KVM, but people have different needs from hypervisors and KVM won't fit all of them. For example, lightweight container-based approaches are better for some virtualization problems (particularly where you really need to run 100s or 1000s of guests on a single machine), and people will still be running Xen and VMWare for many years to come. [...] > What would be nicer is a VM management protocol build in to QEMU, KVM > and XEN, which is a bit like the monitor, but supports multiple client > connections and overlapping operations (where reasonable), and is a > bit more structured, so e.g. you can get the state of anything whose > state you can set, you can wait for events, etc. The somewhat > object-based config file work that's been discussed not long ago would > be a good thing to structure it around. This is what libvirt gives you (and lots more, eg. secure remote access to hypervisors, bindings to Perl & many other languages, etc.). Can you be more specfic about what you couldn't do with libvirt? Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://et.redhat.com/~rjones/virt-top -- Libvir-list mailing list Libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list