qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Alexander Graf
Subject: [Qemu-devel] Re: libvirt vs. in-qemu management
Date: Tue, 06 Apr 2010 14:43:47 +0200
User-agent: Thunderbird 2.0.0.23 (X11/20090817)

Daniel P. Berrange wrote:
> On Mon, Apr 05, 2010 at 11:11:48PM +0200, Alexander Graf wrote:
>   
>> Howdy,
>>
>> I've been thinking a bit further on the whole issue around 
>> libvirt and why the situation as is isn't satisfying. I came
>> to the following points that currently hurt building ease of
>> use for KVM:
>>
>> 1) Brand
>>
>> This is one of the major issues we have ourselves when it comes
>> to appliances. We can ship appliances built for VMware. We can 
>> ship appliances built for Xen. But we can't ship appliances 
>> built for KVM, because there is no single management app we could
>> target. That destroys the KVM brand IMHO.
>>     
>
> With appliances there are two core aspects
>
>  1. The description of VM hardware requirements
>  2. The disk format
>
> Traditionally VMware appliances have shipped a VMX file for 1. and
> a VMDK file for 2. 
>
> Shipping the native config file format with an appliance though is
> the wrong thing to be doing. The native config format describes the
> configuration for a VM for a specific deployment. This is not the
> same as describing the hardware requirements of an appliance. As
> the most simple example, a native config would have hardcoded disk
> paths, or a specific choice of host network connectivity. Neither
> of these things have any business being in the appliance config.
>
> For this reason, there are now specific appliance formats. Libvirt
> has long had its own appliance format (virt-image) which is separate
> from the main XML format, so it avoids hardcoding deployment specific
> options. There is also the vendor neutral OVF format which is widely 
> supported by many mgmt tools. 
>
> If people want to ship QEMU appliances I don't think libvirt is 
> causing any problems here. Simply ship a OVF description + either
> raw or qcow2 disk image. Any app, libvirt, or not could work with
> that.
>   

Does VMware Player support OVF?
Does VMware Workstation support OVF?
Does VMware Server support OVF?
Do older VMware ESX versions support OVF?
Does it make sense to build an OVF with a Xen PV image?

We need to deliver vendor specific configs anyways. Of course we could
ship a VMware type, a Xen type and an OVF type. But that would certainly
not help KVM's awareness because it's hidden underneath the OVF type.

It's also hard to tell people what to use. People know KVM. But people
don't know what UI KVM does have. Because there is none. I think we're
losing quite a bit of traction due to that.

>   
>> 2) Machine description
>>
>> If we build an appliance, we also create a configuration file that
>>  describes the VM. We can create .vmx files, we can create xen config
>> files. We can not create KVM config files. There are none. We could
>> create shell scripts, but would that help?
>>     
>
> As described above, appliances really don't want to be using the 
> native configuration formats, they want a higher level format like
> OVF. The only reason soo many people ship .vmx files is that this
> predates the OVF format's existance.
>
> With qdev you can load most options from a config file using the new
> '-readconfig <file>' arg, but i guess there's more to be included
> there still. 
>   

Getting to a full machine config file is still some way to go, yes. And
as I stated before - I'd love to see that being the default format for
VM storage. If you like management apps could then import and export
those files, but it would still be the point of knowledge. If someone
knows how to hack that description file they'd know how to do it for
every single management app out there. Worst case they'd have to export
and import again.

>   
>> 3) Configuration conversion
>>
>> Party due to qemu not having a configuration format, partly due to 
>> libvirt's ambivalent approach, there is always conversion in 
>> configuration formats involved. I think this is the main reason for
>> the feature lag. If there wasn't a conversion step, there wouldn't 
>> be lag. You could just hand edit the config file and be good.
>>     
>
> [snip]
>
>   
>> 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. In XML. Bleks.
>>     
>
> In the previous thread on this topic, I've already stated that we're
> interested in providing a means to pass QEMU config options from
> libvirt prior to their full modelling in the XML, to reduce, or completely 
> eliminate any time-lag in using new features.
>   

That would cover new features and would be really good to have
nevertheless. It still doesn't cover the difference in configuration for
native tags. Imagine you'd want to enable cache=none. I'd know how to do
it in qemu, but I'd be lost in the libvirt XML. If I'd be a person
knowledgeable in libvirt, I'd know my way around the XML tags but
wouldn't know what they'd mean in plain qemu syntax. So I couldn't tell
people willing to help me what's going wrong even if I wanted to.

If instead there was a common machine description file that everyone
knows, there'd be a single point of knowledge. A RHEL-V admin could work
on plain qemu. A qemu developer would feel right at home with virt-manager.

>
>   
>> Reading on IRC I seem to not be the only person thinking that, just 
>> the first one mentioning this aloud I suppose. But that whole XML mess
>> really hurts us too. Nobody wants to edit XML files. Nobody wants to 
>> have two separate syntaxes to describe the same thing. It complicates
>> everything without a clear benefit. And it puts me in a position where 
>> I can't help people because I don't know the XML format. That should 
>> never happen.
>>     
>
> Even if an app was using QEMU directly, you can't presume that the app 
> will use QEMU's config file as its native format. Many apps will store
> configs in their own custom format (or in a database) and simply generate
> the QEMU config data on the fly when starting a VM. In the same way libvirt
> will  generate QEMU config data on the fly when starting a VM. Having many
> config formats & conversion / generation of the fly is a fact of life no 
> matter what mgmt system you use.
>   

I don't see why we shouldn't try to change that. Why not generate a
common machine description file in qemu for all qemu VMs? Think of word
documents. Everyone knows how to read and write .doc files. Why
shouldn't VM description files be the same? It's really the best case
for the user if there's a single type of configuration.

> The key point is that it needs to be really easy to get at the generated
> QEMU config data to see what is actually being run. libvirt will always
> save the exact QEMU config data it generates into a log file for this
> exact purpose (/var/log/libvirt/qemu/$VMNAME.log).  The complexity here
> is that you can't directly run this if TAP devices are in use for the
> networking since it'll expect TAP FDs to be passed down. Although you 
> could allow QEMU to open the TAP devices, this is not good  for security 
> separation of QEMU from the host OS, so I'm not sure it can be easily
> avoided. 
>   

Sounds like that particular feature needs to go into the qemu stack
then, so it can be properly described in the config file.

> One attempt to make life easier, was that we added a libvirt command 
> 'virsh domxml-to-native' command which given a libvirt XML config file
> would return a set of QEMU command line args which *can* be used to
> start the VM directly. This is basically identical to the normal QEMU
> args libvirt generates but relies on the ifup script to create TAP
> networking instead.
>   

That helps for XML -> qemu. It doesn't help when you're trying to go the
other way around. You'd still have to learn a different syntax. People
are reluctant to learn new syntaxes.

Alex





reply via email to

[Prev in Thread] Current Thread [Next in Thread]