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

[Alexander Graf]

Daniel P. Berrange wrote:
> On Tue, Apr 06, 2010 at 01:14:36AM +0300, Avi Kivity wrote:
>   
>> On 04/06/2010 12:11 AM, Alexander Graf wrote:
>>
>>     
>>> 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.
>>>       
>> Not just libvirt, virt-manager as well.  And that is typically more 
>> difficult technically (though probably takes a lot less time).
>>
>>     
>>> In XML. Bleks.
>>>   
>>>       
>> Yeah.
>>     
>
> Whether XML is a problem or not really depends on what kind of stack you
> are looking at, and what group of users you're considering. 
>
>  1. virsh -> QEMU 
>
>     This is the lowest level in libvirt, so XML is exposed to people
>     directly. We're really not expecting people to use this for 
>     creating new VMs though precisely because people don't like XML,
>     instead see next option. You can hot-plug/unplug devices without
>     knowing XML though.
>
>  2. virt-install -> QEMU
>
>     Instead of XML this takes simple command line args to describe the
>     VM configuration, avoiding need to know XML at all. it also automates
>     many other aspects like creation of storage, fetching of install
>     media, etc.
>
>  2. virt-manager -> libvirt -> QEMU
>
>     Not a GUI, so XML is not exposed to users at all
>
>  3. ovirt/rhev-m -> libvirt -> QEMU
>
>     Configuration is stored in a custom database schema. XML is merely
>     generated on the fly when spawning VMs.
>
>  4. CIM/DMTF -> libvirt -> QEMU
>
>     Configuration is described in terms of DMTF schema, translated
>     on the fly to libvirt XML. Apps using CIM likely don't use the
>     DMTF schema directly either, having their own format.
>
> With exception of the lowest level virsh, XML is just an intermediate
> interchange format, not the format that is directly exposed to users.
> You can get at the raw QEMU level config that results in all cases.
>
> There is a gap in this though, for people who don't want to use any kind
> of management tool at all, but rather just script the low level bits 
> directly. For them, virt-install may not be flexible enough, but virsh
> is too raw forcing knowledge of the XML format. 
>   

Yikes. So that means people do one more conversion step? That sounds
like the worst thing possible. It sounds like a basic -> fortran -> C
converter. That's prone to fail and I'm sure a serious headache for
everyone involved. There's no way people could easily debug things on
such a complex stack anymore.

>   
>>> 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.
>>>   
>>>       
>> It doesn't make sense for libvirt to be hypervisor agnostic.  If it is, 
>> people who want to use one hypervisor's advanced features are forced to 
>> work around it.  Anthony wants multiple monitors for this, but that's a 
>> bad workaround.  libvirt is placing developers using it in an impossible 
>> situation - the developers want to use kvm-specific features and libvirt 
>> is in the way.
>>     
>
> I have proposed a couple of extensions to address this problem of feature
> lg
>
>  - Provide a way to pass extra command line args to QEMU via libvirt
>  - Provide a way to send/receive monitor commands via libvirt
>
> This would give access to nearly all of QEMU's features.
>   

It's more than just feature lag. Anthony is the one caring about feature
lag. I care about too many levels of abstraction and conversion. Try to
think as if you were a sysadmin trying to create VMs. You would have to
learn two different languages (libvirt-xml and qemu syntax) to be able
to really work with the whole stack. Because the stack consists of both.
You also need to go back and forth between the two at times. So you
really do end up having to learn both, which is bad.

What I was trying to point out is that we should make things easier for
users by keeping things consistent and always the same syntax-wise. That
makes everyone's life a lot easier.

If you try to disagree with me, try switching to csh from bash. It can
do the same thing with the same applications your bash calls. It's
merely a different syntax. Now try to be productive with it :-).


Alex