qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [et-mgmt-tools] Re: [libvirt] RE: [Qemu-devel] [ANNOUNCE] virt-mem t


From: Jamie Lokier
Subject: Re: [et-mgmt-tools] Re: [libvirt] RE: [Qemu-devel] [ANNOUNCE] virt-mem tools version 0.2.8 released
Date: Sun, 10 Aug 2008 02:28:27 +0100
User-agent: Mutt/1.5.13 (2006-08-11)

Javier Guerra wrote:
> On Thu, Aug 7, 2008 at 8:06 AM, Richard W.M. Jones <address@hidden> 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.

Also, I wanted to import existing guests from another VM, and
libvirt's tools seemed strongly geared around creating new VMs to use
with libvirt.  So I had to write config files for it - see above.

I like the idea of libvirt a lot and wish it well.

My own Perl script was a nightmare to write even though it's not so
long (synchronisation & monitor issues especially), so I respect
what's done.  It's a good goal.

But I just found it too confusing to use in the ways I needed to use
KVM, that I gave up on libvirt for now rather than spend the
considerable time to get to grips with what it's doing, and it's
config format.

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.

-- Jamie




reply via email to

[Prev in Thread] Current Thread [Next in Thread]