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

[Alexander Graf]

Daniel P. Berrange wrote:
> On Tue, Apr 06, 2010 at 02:49:23PM +0200, Alexander Graf wrote:
>   
>> 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.
>>     
>
> The different formats are serving different needs really. People use the
> libvirt XML format because they want a representation that works across
> multiple hypervisors. There is a CIM/DMTF mapping because apps using that
> system want to take advtange of the libvirt representation. Apps like
> ovirt/rhev-m have their own master representation because the other formats
> are far too low level for their needs.  They higher up the stack you go the
> less likely people are to want to use the low level config format directly.
>   

I'm fairly sure it's true that most people don't want to use low level
config formats. But as soon as you start debugging you will have to go
through the full stack. And so you'll need to know every single protocol
and conversion. As every one of the layers can fail.

>   
>> 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.
>>     
>
> That really depends on the target audience. Most end users people won't 
> see or care about either the QEMU format, or the libvirt XML format. 
> Most of the time the libvirt format will give everything you need and so
> you don't care about the QEMU format either.
>
> You only need to care about multiple formats if you're trying todo things
> at multiple levels of the stack at once, which should always be a minority
> usecase/scenario.
>   

Debugging requires you to traverse the full stack. Developing does too.

What I'm currently seeing is two distinct worlds of VM descriptions
(libvirt vs. qemu) and when looking at the #kvm IRC channel, people who
know their way around qemu usually can't help people using the libvirt
description because they just don't know it. I don't see why they
shouldn't. People who know their way around lower parts of the stack
should also be able to help out others on higher levels.

>   
>> 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 :-).
>>     
>
> This is a false analogy. csh & bash are two different implenetations at the
> same level in the stack.  Compare libX11 against libgtk if you want a more
> sensible comparison. libgtk provides 99% of the features you need. In rare
> cases where it doesn't, you can get access to libX11 APIs directly, but that
> doesn't imply that everyone using GTK needs to know X11.  Your argument
> against libvirt is akin to saying that since GTK can't ever support 100% of
> the X11 functionality, people shouldn't use GTK and apps should work against
> X11 directly. 
>   

Yes and no. In that analogy I'm saying "let's throw away the GTK API and
the X11 API and develop something that works for both layers". I'd love
to see -net bridge in qemu for example. Network setup is just too
complicated as it is now. And I believe offshoring that is the wrong
direction to take.


Alex