qemu-devel
[Top][All Lists]
Advanced

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

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


From: Michael S. Tsirkin
Subject: Re: [Qemu-devel] [PATCH] [RFC] Add machine type pc-1.0-qemu-kvm for live migrate compatibility with qemu-kvm
Date: Mon, 4 Aug 2014 15:34:28 +0200

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.


> -- 
> Alex Bligh
> 
> 
> 



reply via email to

[Prev in Thread] Current Thread [Next in Thread]