"Daniel P. Berrange" <berrange@xxxxxxxxxx> 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 <alex@xxxxxxxxxxx> >> >> 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". -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list