[libvirt] [Qemu-devel] [PATCH v4] Add machine parameter qemu-kvm-migration for live migrate compatibility with qemu-kvm
Michael S. Tsirkin
mst at redhat.com
Sun Oct 5 12:48:52 UTC 2014
On Sun, Oct 05, 2014 at 08:26:45AM -0400, Paolo Bonzini wrote:
> > > > If you were just objecting to the fact that pc-1.0 was made to
> > > > be an alias of either one or the other at compile time, simply
> > > > drop the second patch of the v2 patchset.
> > >
> > > I was objecting to making pc-1.0 special. There's nothing special in
> > > pc-1.0, other machine types also had differences between qemu-kvm and
> > > qemu. And I do not think that upstream has any reason to make pc-1.0
> > > special.
> >
> > OK, so in v5, pc-1.0 is unchanged, and not made special. A new machine
> > type is added which allows import from something (unfortunately) called
> > pc-1.0 in something in qemu's past, as well as some distributions.
>
> The very fact that a clone of pc-1.0 is added, but not pc-0.15 or
> pc-1.2, makes pc-1.0 special.
>
> My proposal has always been that _all_ PC machines should have a property.
> This could be done, for example, by starting with Eduardo's patches that
> make a class hierarchy of PC machine types.
>
> pc-1.0 is special in Ubuntu world, because it was in an LTS release. This
> is why this patch should be added to Ubuntu, not to upstream. pc-1.0 is
> not necessarily special in other distros. And some of them (Fedora for
> example) are _always_ treating their machine types as the qemu-kvm variants,
> and have been doing so for
> a couple years.
>
> I very strongly object to including a patch upstream that is tailored
> after a particular downstream, and just because that particular downstream
> has failed in doing the integration testing that it was supposed to do.
>
> > > So, if Ubuntu is okay with breaking pc-1.0 migration from 14.04-old to
> > > 14.04-new, the right thing to do is simply that Ubuntu makes its pc-1.0
> > > machine type the qemu-kvm one. No new machine types, no aliases, no
> > > anything.
> >
> > That would not allow Ubuntu (or Suse - similarly affected I think)
> > to import pc-1.0 VMs from things actually running pc-1.0, and would
> > mean that newly created pc-1.0 VMs would be 'wrong', perpetuating
> > the problem.
>
> The problem _is_ perpetual. "pc-1.0" makes no sense without a context
> (the distro). This is why it is not a problem for Fedora to always use
> the qemu-kvm variants.
>
> "pc-1.0" will always be the qemu-kvm variant in Ubuntu context (apart
> from the 6 months passed since the release of 14.04), because most
> "pc-1.0" machines will have been created with the qemu-kvm package in
> Ubuntu 12.04.
>
> It can be confusing---to avoid confusion, RHEL drops the upstream machine
> types apart from the "pc" generic type and adopts a completely different
> nomenclature.
>
> In fact as time passes the benefit of 12.04->14.04 migration becomes
> smaller and smaller and, by now, it should have gone almost completely.
> It's much simpler to ignore the problem at this point. For the next
> Ubuntu LTS, Canonical should include migration compatibility in their
> test plans. And start well in advance, for it may only take one
> person to fix the bugs, but it takes months of testing to find them.
>
> Paolo
In fact, if the pc_piix bits are dropped from the patch,
you get a generic patchset that does exactly what you ask,
correct?
Downstream can then enable qemu-kvm compatibility by adding:
-global cirrus-vga.vgamem_mb=16 -global pit-common.qemu-kvm-migration=on
-global PIIX4_PM.qemu-kvm-migration=on
--
MST
More information about the libvir-list
mailing list