Re: [RFC] Unify KVM kernel-space and user-space code into a single project

[Alexander Graf <agraf@suse.de>]

On 22.03.2010, at 20:31, Daniel P. Berrange wrote:

> On Mon, Mar 22, 2010 at 02:15:35PM -0500, Anthony Liguori wrote:
>> On 03/22/2010 12:55 PM, Avi Kivity wrote:
>>>> Lets look at the ${HOME}/.qemu/qmp/ enumeration method suggested by 
>>>> Anthony.
>>>> There's numerous ways that this can break:
>>> 
>>> I don't like it either.  We have libvirt for enumerating guests.
>> 
>> We're stuck in a rut with libvirt and I think a lot of the 
>> dissatisfaction with qemu is rooted in that.  It's not libvirt that's 
>> the probably, but the relationship between qemu and libvirt.
>> 
>> We add a feature to qemu and maybe after six month it gets exposed by 
>> libvirt.  Release time lines of the two projects complicate the 
>> situation further.  People that write GUIs are limited by libvirt 
>> because that's what they're told to use and when they need something 
>> simple, they're presented with first getting that feature implemented in 
>> qemu, then plumbed through libvirt.
> 
> That is somewhat unfair as a blanket statement! 
> 
> While some features have had a long time delay & others are not supported
> at all, in many cases we have had zero delay. We have been supporting QMP,
> qdev, vhost-net since before the patches for those features were even merged
> in QEMU GIT! It varies depending on how closely QEMU & libvirt people have
> been working together on a feature, and on how strongly end users are demanding
> the features. 

Yes. I think the point was that every layer in between brings potential slowdown and loss of features.

Hopefully this will go away with QMP. By then people can decide if they want to be hypervisor agnostic (libvirt) or tightly coupled with qemu (QMP). The best of both worlds would of course be a QMP pass-through in libvirt. No idea if that's easily possible.

Either way, things are improving. What people see at the end is virt-manager though. And if you compare if feature-wise as well as looks-wise vbox is simply superior. Several features lacking in lower layers too (pv graphics, always working absolute pointers, clipboard sharing, ...).

That said it doesn't mean we should resign. It means we know which areas to work on :-). And we know that our problem is not the kernel/userspace interface, but the qemu and above interfaces.

Alex