[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [libvirt] [Qemu-devel] [PATCH] [RFC] Add machine type pc-1.0-qemu-kvm for live migrate compatibility with qemu-kvm



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?


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]