Il 29/09/2014 09:02, Markus Armbruster ha scritto: >> 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. 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. For upstream, the option is acceptable because that one applies just as well to other types than 1.0. Other distros included 0.15 or 1.2, and can use the option as well. >> If we have a new machine type, I don't /think/ I need the early_init >> thing at all (I may be wrong about that). You can add a new property to the machine, and do the early_init work in the property setter, I think. > I also prefer a new machine type. > > Ideally, the management application understands that there are two > incompatibile versions QEMU (upstream and old qemu-kvm), and how to map > their machine types to current QEMU's. That would mean patching the Ubuntu libvirt, right? At this point it's simpler to just patch Ubuntu QEMU to do what you write here: > If that's not practical, then downstream can still alias the machine > types around to make things just work in the most important downstream > scenarios. The most important upstream scenario is QEMU <-> QEMU, of > course. I'm not sure why this patch is of any interest upstream... Paolo -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list