On Mon, Aug 04, 2014 at 04:47:11PM +0100, Alex Bligh wrote:
On 4 Aug 2014, at 16:38, Serge Hallyn <serge.hallyn@ubuntu.com> wrote:
If you really want it to be called pc-1.0, you can make it a machine property instead. E.g. qemu-kvm-compatibility. Teach management to set it if remote is qemu-kvm: -machine pc-1.0,qemu-kvm-compatibility=on
That sounds nice - Alex, what do you think?
Not having used the machine property stuff before, or played with libvirt much, I'm not sure how this helps libvirt.
I thought the issue here was that migrating from 1.0-qemu-kvm to 2.x OR 1.0-qemu-git to 2.x, libvirt is going to to supply the same command line. As libvirt doesn't know what the sender is (and it's not possible to detect this automatically - at least not without a far more intrusive patch),
Yes, this is up to higher level user. At libvirt xml level, you would just specify something like "legacy qemu-kvm compatibility" in the xml.
one has to make a choice at build time as to what 'pc-1.0' represents.
There's no choice really. Downstreams must make sure their machine types are distinct from upstream ones. qemu-kvm as a downstream violated this rule but I don't think this means upstream should violate it.
This is what patch #2 does. I fully agree it is not pretty.
The problem is not prettyness. The problem is, it creates a situation where two instances of qemu have different ideas about what a specific machine type is.
So I am not sure why -machine pc-1.0,qemu-kvm-compatibility=on is any easier for libvirt than -machine pc-1.0-qemu-kvm
IE what does using a machine property rather than a machine type buy us?
Seems to be easier to understand that it maps to pc-1.0 on the other side.
-- Alex Bligh