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

[Daniel P. Berrange]

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. 

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

Regards,
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 :|