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 -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list