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

[Daniel P. Berrange]

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.


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