From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:45797) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XEKLm-0003n6-EO for qemu-devel@nongnu.org; Mon, 04 Aug 2014 11:39:09 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XEKLe-0007d2-SX for qemu-devel@nongnu.org; Mon, 04 Aug 2014 11:39:02 -0400 Received: from youngberry.canonical.com ([91.189.89.112]:40748) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XEKLe-0007cv-Lt for qemu-devel@nongnu.org; Mon, 04 Aug 2014 11:38:54 -0400 Date: Mon, 4 Aug 2014 15:38:47 +0000 From: Serge Hallyn Message-ID: <20140804153847.GE12438@ubuntumail> References: <1406054580-16763-1-git-send-email-alex@alex.org.uk> <7DADE58E-0CA0-4B97-9567-AAF5ECBC47AA@alex.org.uk> <20140729041630.GN464@ubuntumail> <82F2A47F-F096-458C-B511-26116BE78DFA@alex.org.uk> <20140804133428.GB17436@redhat.com> <20140804150831.GI9893@ubuntumail> <20140804152650.GB18760@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140804152650.GB18760@redhat.com> Subject: Re: [Qemu-devel] [PATCH] [RFC] Add machine type pc-1.0-qemu-kvm for live migrate compatibility with qemu-kvm List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Michael S. Tsirkin" Cc: Ryan Harper , Serge Hallyn , "quintela@redhat.com" , Libvirt , "qemu-devel@nongnu.org" , Alexander Graf , Alex Bligh , Cole Robinson , Amit Shah , Paolo Bonzini , Bruce Rogers , Andreas =?iso-8859-1?Q?F=E4rber?= Quoting Michael S. Tsirkin (mst@redhat.com): > On Mon, Aug 04, 2014 at 03:08:31PM +0000, Serge Hallyn wrote: > > Quoting Michael S. Tsirkin (mst@redhat.com): > > > On Tue, Jul 29, 2014 at 08:31:28AM +0100, Alex Bligh wrote: > > > > Serge, > > > > > > > > > I don't think that is in any way a problem. Is migrating to older > > > > > versions ever actually expected to work? In either case I don't > > > > > think for this particular case it's a problem. > > > > > > > > Good; no; and good - respectively. > > > > > > > > > (The "how to handle this in libvirt" question is more interesting) > > > > > > > > I've been giving this some thought. However rococo we make this, > > > > I think the caller is often going to need to modify the command > > > > line anyway, i.e. is going to need to be aware of the migration > > > > problem. > > > > > > > > For instance, taking Ubuntu as an example, 12.04 shipped with > > > > qemu-kvm-1.0, and a pxe-virtio.rom of just under 64k, giving > > > > a 64k ROM slot. 14.04 ships with qemu-2.0 and a pxe-virtio.rom > > > > of over 80k, giving a 128k ROM slot. So however we fix the > > > > machine types, when migrating in a 12.04 initiated VM, qemu > > > > will need > > > > -global virtio-net-pci.romfile=/path/to/pxe-virtio.rom.12.04 > > > > on the command line (or, if you don't much care about PXE > > > > working on a soft reboot, a blank file of the same size), > > > > whereas when migrating in a 14.04 initiated VM, that must > > > > not be on the command line. > > > > > > > > Fixing this properly would entail requiring that the ROMs are > > > > (effectively) distributed with qemu or at least that all > > > > ROM sizes become part of the machine type standard. This > > > > would have the advantage that loading a larger ROM than > > > > the machine type specifies would fail unless the ROM > > > > size was explicitly configured on the command line. But > > > > this is a subject wider than this patch. > > > > > > > > So the long and the short of it is that libvirt (sadly) like > > > > anything else starting qemu machines needs to know a bit about > > > > different versions of qemu, and be able to replace a machine > > > > type option with a machine type option and more on the > > > > command line. > > > > > > > > My previous suggestion doesn't help much because qemu will > > > > still need to be passed something on the command line. > > > > > > > > I think the best way to go with this patch would be something > > > > like: > > > > > > > > * Add pc-1.0-qemu-kvm as a machine type (done) > > > > > > > > * Rename pc-1.0 to pc-1.0-qemu-git > > > > > > > > * Add an alias for pc-1.0 to either pc-1.0-qemu-git or > > > > pc-1.0-qemu-kvm, configurable at build time with > > > > a ./configure option. The distro can then set this > > > > appropriately. This would default to pc-1.0-qemu-git > > > > (i.e. the current behaviour). > > > > > > > > On distros that only every used one of the above, > > > > ./configure will sort things out, +/- self-inflicted > > > > injuries relating to ROM size changes. If life is > > > > more complicated, libvirt (and other callers) will > > > > need to be aware. pc-1.0-qemu-git and pc-1.0-qemu-kvm > > > > can be used to unambiguously mean the relevant machine > > > > type, which will fix things going forward for that > > > > machine type. > > > > > > > > WDYT? > > > > > > > > > This just means we perpetuate the broken-ness. > > > > > > I would rather we teach libvirt to do the right thing > > > unconditionally. > > > > Well, now, here's a thought - can we hot-patch qemu to > > change the machine type while it is running before the > > migrate? Just s/pc-1.0/pc-x.0/ or something? > > Frankly I don't see what will this accomplish. > > If you really want it to be called pc-1.0, you > can make it a machine property instead. > E.g. qemu-kvm-compatibility. > Teach management to set it if remote is qemu-kvm: > -machine pc-1.0,qemu-kvm-compatibility=on That sounds nice - Alex, what do you think?