Re: [Qemu-devel] [PATCH v4] Add machine parameter qemu-kvm-migration for live migrate compatibility with qemu-kvm

[Michael S. Tsirkin]

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