Re: [Qemu-devel] [PATCH] [RFC] Add machine type pc-1.0-qemu-kvm for live migrate compatibility with qemu-kvm

["Michael S. Tsirkin" <mst@redhat.com>]

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
> 
> 
>