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: Serge E. Hallyn
Subject: Re: [Qemu-devel] [PATCH] [RFC] Add machine type pc-1.0-qemu-kvm for live migrate compatibility with qemu-kvm
Date: Tue, 29 Jul 2014 15:03:55 +0200
User-agent: Mutt/1.5.21 (2010-09-15)

Quoting Alex Bligh (address@hidden):
> 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?

That sounds good.

And from there I think the thing to do will be to introduce a transient
alternate package that has the pc-1.0 alias pointing ot pc-1.0-qemu-kvm and
depends on the legacy pxe rom.  And maybe users can then choose that package for
migration purposes if needed, without having to make any changes to libvirt at
all, while others are completely unaffected.

-serge



reply via email to

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