[Qemu-devel] libvirt vs. in-qemu management

[Alexander Graf]

Howdy,

I've been thinking a bit further on the whole issue around libvirt and why the 
situation as is isn't satisfying. I came to the following points that currently 
hurt building ease of use for KVM:

1) Brand

This is one of the major issues we have ourselves when it comes to appliances. 
We can ship appliances built for VMware. We can ship appliances built for Xen. 
But we can't ship appliances built for KVM, because there is no single 
management app we could target. That destroys the KVM brand IMHO.

2) Machine description

If we build an appliance, we also create a configuration file that describes 
the VM. We can create .vmx files, we can create xen config files. We can not 
create KVM config files. There are none. We could create shell scripts, but 
would that help?

3) Configuration conversion

Party due to qemu not having a configuration format, partly due to libvirt's 
ambivalent approach, there is always conversion in configuration formats 
involved. I think this is the main reason for the feature lag. If there wasn't 
a conversion step, there wouldn't be lag. You could just hand edit the config 
file and be good.


Point 2 needs to be solved anyways. We need a machine config format for qemu. 
For general -M description as well as for specific VM description. The command 
line options just become too complicated and too hard to reproduce and save. 
Just think of live migration with hot-plugged devices. Or safe savevm + loadvm. 
The current logic ends there.

I can imagine 1) going away if we would set libvirt + virt-manager as _the_ 
front-end and have everyone focus on it. I suppose it would also help to 
rebrand it by then, but I'm not 100% sure about that. Either way, there would 
have to be a definite statement that libvirt is the solution to use. And 
_everyone_ would have to agree on that. Sounds like a hard task. And by then we 
still don't really have a branded product stack.

Point 3 is the really tough one. It's the very basis of libvirt. And it's plain 
wrong IMHO. I hate XML. I hate duplicated efforts. The current conversion 
involves both. Every option added to qemu needs to be added to libvirt. In XML. 
Bleks.
Reading on IRC I seem to not be the only person thinking that, just the first 
one mentioning this aloud I suppose. But that whole XML mess really hurts us 
too. Nobody wants to edit XML files. Nobody wants to have two separate syntaxes 
to describe the same thing. It complicates everything without a clear benefit. 
And it puts me in a position where I can't help people because I don't know the 
XML format. That should never happen.

Sure, for libvirt it makes sense to be hypervisor-agnostic. For qemu it 
doesn't. We want to be _the_ hypervisor. Setting our default front-end to 
something that is agnostic weakens our point. And it slows down development. 
And it hurts integration. And thus usability, thus adoption. It hurts us.


That's what I've concluded so far on the whole situation as is. I find it sad 
to be the one speaking it out, but IMHO going with libvirt as default 
management front-end is a dead end. It will hurt us more than it will help us.

That said I don't think it'd be bad to cooperate or encourage people to use 
libvirt. In fact I believe the opposite - it's great if you want to be 
agnostic. It just isn't when you're not. And we should differentiate there.


Alex