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: Alex Bligh
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 08:31:28 +0100

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?

-- 
Alex Bligh







reply via email to

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