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

[Alexander Graf]

Daniel P. Berrange wrote:
> On Tue, Apr 06, 2010 at 03:53:16PM +0200, Alexander Graf wrote:
>   
>> Daniel P. Berrange wrote:
>>     
>>>> 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.
>>>>     
>>>>         
>>> This isn't solving the problem. If you see a problem in the QEMU config
>>> uses by a high level tool like RHEV/oVirt, you still aren't going to 
>>> know what the config change you need to make in those apps. They are
>>> never going to work with the QEMU config as their master data format.
>>> It is just something they generate on the fly at runtime, from their
>>> SQL databases, because they want to model concepts at a high level.
>>> A VM as represented in RHEV/oVirt does not have a single QEMU or libvirt
>>> config file description - the low level config can potentially vary each
>>> time the guest is started on a host(s).
>>>   
>>>       
>> So we could still make it transparent to the user, no? RHEV could import
>> a KVM machine description as well as it could export one. So the
>> internal representation is transparent to the user. That would also ease
>> going from RHEV to other management apps. Or the other way around.
>>
>>     
>>>   
>>>       
>>>>> 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 raw QEMU config for a disk device is specified in terms of the
>>> file path for the storage.  A management app using QEMU / libvirt is
>>> not going to store its config for the guest in this way. They will
>>> have some model of storage and an association between a storage volume
>>> and a virtual machine. The actual file path for this may is only relevant
>>> at the time the VM is actually started & may be different on every host
>>> the VM is run on. eg if you've associated a VM with a LUN based, it may
>>> be /dev/sda when run on host A and /dev/sdz on host B. The mgmt app is
>>> going to use a mapping based on the  WWID, not paths. 
>>>   
>>>       
>> Sounds like somebody didn't understand the concept of persistent device
>> names here. The device names should be /dev/disk/by-wwid/... then.
>>     
>
> To find out either the /dev/sdXX or /dev/disk/by-XXX paths you need to
> setup the storage on one of the hosts. At the time the VM is being
> configured in the app you can't presume that the storage is visible on
> any of the hosts. The /dev/disk/by-XXX paths are only stable for the
> type of physical storage. Modelling the VM <-> storage association based 
> on any kind of file path is fundamentally the wrong level of representation
> for high level apps. By modelling based on a application specific logical
> association, the storage can be moved between filesystems, moved from a
> file to an LVM lv, to a SAN etc, without ever breaking the assocation at
> an application level. 
>
> Fundamentally, a QEMU level configuration is a description of a specific
> instantiation of a VM. An application level configuration is a description
> of a VM that can be instantiated in many ways. There's a 1 <-> M relation
> between application level config description & QEMU level config file.
> Thus in many cases a QEMU config will not be usable as an application's
> master config format.
>   

Hrm.

So what if you had a special section that gives you the necessary
information to do that mapping? A vendor specific section so to say.
That would make it a perfect master config format, right?


Alex