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

[Daniel P. Berrange]

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.

> 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.

> 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. 

Daniel
-- 
|: Red Hat, Engineering, London    -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://deltacloud.org :|
|: http://autobuild.org        -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|