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

[Serge Hallyn <serge.hallyn@ubuntu.com>]

Quoting Michael S. Tsirkin (mst@redhat.com):
> On Mon, Sep 22, 2014 at 05:24:55PM +0200, Markus Armbruster wrote:
> > "Daniel P. Berrange" <berrange@redhat.com> 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@alex.org.uk>
> > >> 
> > >> 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".
> 
> Right, but IMHO doing it at compile-time is wrong.
> If distros want compatiblity with both sometimes, what then?
> Build two binaries with different flags?
> Should be a runtime option that management sets after (somehow?)
> figuring out what's going on, on source.
> 
> How does it do that? Not sure - but I'm sure destination distro has no
> way to figure it out.

It's not even just between distributions.  Anyone who used qemu-2.0 to
start a pc-1.0 machine type will have a different mt than someone who
starts a vm under Ubuntu's (qemu-)kvm 1.0.  Sadly.

So in the packages at https://launchpad.net/~serge-hallyn/+archive/ubuntu/qemu-p-migration
the default can be configured at build-time, but it can be specified on
the command-line (which is then controlled by a new libvirt flag).

-serge