From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NzAMU-0001tu-Nw for qemu-devel@nongnu.org; Tue, 06 Apr 2010 11:06:42 -0400 Received: from [140.186.70.92] (port=60803 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NzAMO-0000ad-5n for qemu-devel@nongnu.org; Tue, 06 Apr 2010 11:06:42 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1NzAMF-0002kX-Sg for qemu-devel@nongnu.org; Tue, 06 Apr 2010 11:06:33 -0400 Received: from cantor.suse.de ([195.135.220.2]:59494 helo=mx1.suse.de) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1NzAMF-0002jv-J6 for qemu-devel@nongnu.org; Tue, 06 Apr 2010 11:06:27 -0400 Message-ID: <4BBB4DEF.4070407@suse.de> Date: Tue, 06 Apr 2010 17:06:23 +0200 From: Alexander Graf MIME-Version: 1.0 References: <20100406104704.GJ28689@redhat.com> <4BBB2C83.50103@suse.de> <20100406133939.GP28689@redhat.com> <4BBB3CCC.3000208@suse.de> <20100406140633.GQ28689@redhat.com> In-Reply-To: <20100406140633.GQ28689@redhat.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] Re: libvirt vs. in-qemu management List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Daniel P. Berrange" Cc: Anthony Liguori , qemu-devel Developers , Avi Kivity 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