Re: [Qemu-devel] [libvirt] [PATCH v3 2/2] Add configure option --enable-pc-1-0-qemu-kvm

[Markus Armbruster]

"Daniel P. Berrange" <address@hidden> writes:

> On Mon, Sep 22, 2014 at 02:36:55PM +0300, Michael S. Tsirkin wrote:
>> On Sun, Sep 21, 2014 at 03:38:59PM +0100, Alex Bligh wrote:
>> > Add a configure option --enable-pc-1-0-qemu-kvm and the
>> > corresponding --disable-pc-1-0-qemu-kvm, defaulting
>> > to disabled.
>> > 
>> > Rename machine type pc-1.0 to pc-1.0-qemu-git.
>> > 
>> > Make pc-1.0 machine type an alias of either pc-1.0-qemu-kvm
>> > or pc-1.0-qemu-git depending on the value of the config
>> > option.
>> > 
>> > Signed-off-by: Alex Bligh <address@hidden>
>> 
>> I have to say, this one bothers me.
>> We end up not being able to predict what does pc-1.0
>> reference.
>
> Yeah, this is not good. Any single machine type name should have
> fixed semantics - having two different semantics depending on build
> options means mgmt apps can no longer simply compare the machine
> type name to determine if it is a match with the same name on a
> different host.

You're right.  However, this particular horse left the barn a long time
ago: the pc-* machine types differ in qemu-kvm and upstream QEMU.

Sure, when qemu-kvm was merged back into QEMU, its machine type variants
were dropped.  But they live on in various downstreams that just like
QEMU had to pick between compatibility with upstream QEMU and qemu-kvm,
but unlike QEMU picked compatibility with qemu-kvm.

So this patch does *not* break any management apps by letting them "no
longer simply compare the machine type name to determine if it is a
match with the same name on a different host".  They never could for
these messed up machine types, at least not without knowing exactly what
kind of QEMU runs on the hosts in question.

All this patch does is adding another facet to "exactly what kind of
QEMU".