qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v4] Add machine parameter qemu-kvm-migration for


From: Paolo Bonzini
Subject: Re: [Qemu-devel] [PATCH v4] Add machine parameter qemu-kvm-migration for live migrate compatibility with qemu-kvm
Date: Sun, 05 Oct 2014 09:00:11 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.1

Il 29/09/2014 09:02, Markus Armbruster ha scritto:
>> If you were just objecting to the fact that pc-1.0 was made to
>> be an alias of either one or the other at compile time, simply
>> drop the second patch of the v2 patchset.

I was objecting to making pc-1.0 special.  There's nothing special in
pc-1.0, other machine types also had differences between qemu-kvm and
qemu.  And I do not think that upstream has any reason to make pc-1.0
special.

So, if Ubuntu is okay with breaking pc-1.0 migration from 14.04-old to
14.04-new, the right thing to do is simply that Ubuntu makes its pc-1.0
machine type the qemu-kvm one.  No new machine types, no aliases, no
anything.

For upstream, the option is acceptable because that one applies just as
well to other types than 1.0.  Other distros included 0.15 or 1.2, and
can use the option as well.

>> If we have a new machine type, I don't /think/ I need the early_init
>> thing at all (I may be wrong about that).

You can add a new property to the machine, and do the early_init work in
the property setter, I think.

> I also prefer a new machine type.
> 
> Ideally, the management application understands that there are two
> incompatibile versions QEMU (upstream and old qemu-kvm), and how to map
> their machine types to current QEMU's.

That would mean patching the Ubuntu libvirt, right?  At this point it's
simpler to just patch Ubuntu QEMU to do what you write here:

> If that's not practical, then downstream can still alias the machine
> types around to make things just work in the most important downstream
> scenarios.  The most important upstream scenario is QEMU <-> QEMU, of
> course.

I'm not sure why this patch is of any interest upstream...

Paolo



reply via email to

[Prev in Thread] Current Thread [Next in Thread]