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