Re: [et-mgmt-tools] Re: [libvirt] RE: [Qemu-devel] [ANNOUNCE] virt-mem tools version 0.2.8 released
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(a)redhat.com> 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