[Qemu-devel] live migration + licensing issue.

[Qemu-devel] live migration + licensing issue.

[Anshul Makkar]

Hi,

In our data center we are using qemu 1.0/ 1.2 and we need to do a live
migration to qemu 2.0.

One of the main hindrance that we are facing is that QEMU 1.0 uses old
PC model so if a user using Windows on the VM running on QEMU 1.0 does
a live migrate to QEMU 2.0 , he will see a licensing issue as after
migration Windows will see a new hardware beneath it.

Any suggestion as to how to overcome this problem.

Thanks
Anshul Makkar
www.justkernel.com

Re: [Qemu-devel] live migration + licensing issue.

[Andreas Färber]

Hi,

Am 08.07.2014 17:24, schrieb Anshul Makkar:
> In our data center we are using qemu 1.0/ 1.2 and we need to do a live
> migration to qemu 2.0.
> 
> One of the main hindrance that we are facing is that QEMU 1.0 uses old
> PC model so if a user using Windows on the VM running on QEMU 1.0 does
> a live migrate to QEMU 2.0 , he will see a licensing issue as after
> migration Windows will see a new hardware beneath it.
> 
> Any suggestion as to how to overcome this problem.

Please check the documentation. There's the -machine option with
parameters such as pc-1.0 and pc-1.2 for that exact purpose. libvirt
should supply the corresponding option automatically.

More difficult is if you're trying to migrate from qemu-kvm to qemu -
code changes to your copy of 2.0 will be necessary then.

Regards,
Andreas

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg

Re: [Qemu-devel] live migration + licensing issue.

[Anshul Makkar]

Hi,

Yeah, I am aware of this option. But the point where I am concerned is
that if Windows VM is running in QEMU 1.0 with pc-model 1.0 and then I
upgrade the QEMU to 2.0 and I specify machine as pc-1.2, then Windows
will see this as change in hardware and complain about the license.

Sorry, if my understanding is wrong here or i am missing something.

Anshul Makkar

On Tue, Jul 8, 2014 at 6:25 PM, Andreas Färber <afaerber@suse.de> wrote:
> Hi,
>
> Am 08.07.2014 17:24, schrieb Anshul Makkar:
>> In our data center we are using qemu 1.0/ 1.2 and we need to do a live
>> migration to qemu 2.0.
>>
>> One of the main hindrance that we are facing is that QEMU 1.0 uses old
>> PC model so if a user using Windows on the VM running on QEMU 1.0 does
>> a live migrate to QEMU 2.0 , he will see a licensing issue as after
>> migration Windows will see a new hardware beneath it.
>>
>> Any suggestion as to how to overcome this problem.
>
> Please check the documentation. There's the -machine option with
> parameters such as pc-1.0 and pc-1.2 for that exact purpose. libvirt
> should supply the corresponding option automatically.
>
> More difficult is if you're trying to migrate from qemu-kvm to qemu -
> code changes to your copy of 2.0 will be necessary then.
>
> Regards,
> Andreas
>
> --
> SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
> GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg

Re: [Qemu-devel] live migration + licensing issue.

[Markus Armbruster]

Anshul Makkar <anshul.makkar@profitbricks.com> writes:

> Hi,
>
> Yeah, I am aware of this option. But the point where I am concerned is
> that if Windows VM is running in QEMU 1.0 with pc-model 1.0 and then I
> upgrade the QEMU to 2.0 and I specify machine as pc-1.2, then Windows
> will see this as change in hardware and complain about the license.

Works as designed.

> Sorry, if my understanding is wrong here or i am missing something.

Changing the machine type is the virtual equivalent of replacing the
motherboard.

Re: [Qemu-devel] live migration + licensing issue.

[Anshul Makkar]

Thanks. I got the point.

Anshul Makkar

On Wed, Jul 9, 2014 at 9:36 AM, Markus Armbruster <armbru@redhat.com> wrote:
> Anshul Makkar <anshul.makkar@profitbricks.com> writes:
>
>> Hi,
>>
>> Yeah, I am aware of this option. But the point where I am concerned is
>> that if Windows VM is running in QEMU 1.0 with pc-model 1.0 and then I
>> upgrade the QEMU to 2.0 and I specify machine as pc-1.2, then Windows
>> will see this as change in hardware and complain about the license.
>
> Works as designed.
>
>> Sorry, if my understanding is wrong here or i am missing something.
>
> Changing the machine type is the virtual equivalent of replacing the
> motherboard.

Re: [Qemu-devel] live migration + licensing issue.

[Alexandre DERUMIER]

Hi,

AFAIK this change has occured between the switch from qemu-kvm to qemu. (qemu 1.3 if I remember)

Don't have see license problem after other upgrade (qemu 1.3->1.4->1.5 ...)


But It's always better to use volume licenses, no more problem in case of virtual hardware change.


----- Mail original -----

De: "Anshul Makkar" <anshul.makkar@profitbricks.com>
À: "Markus Armbruster" <armbru@redhat.com>
Cc: "Andreas Färber" <afaerber@suse.de>, "qemu-devel" <qemu-devel@nongnu.org>
Envoyé: Mercredi 9 Juillet 2014 13:09:47
Objet: Re: [Qemu-devel] live migration + licensing issue.

Thanks. I got the point.

Anshul Makkar

On Wed, Jul 9, 2014 at 9:36 AM, Markus Armbruster <armbru@redhat.com> wrote:
> Anshul Makkar <anshul.makkar@profitbricks.com> writes:
>
>> Hi,
>>
>> Yeah, I am aware of this option. But the point where I am concerned is
>> that if Windows VM is running in QEMU 1.0 with pc-model 1.0 and then I
>> upgrade the QEMU to 2.0 and I specify machine as pc-1.2, then Windows
>> will see this as change in hardware and complain about the license.
>
> Works as designed.
>
>> Sorry, if my understanding is wrong here or i am missing something.
>
> Changing the machine type is the virtual equivalent of replacing the
> motherboard.

Re: [Qemu-devel] live migration + licensing issue.

[Andreas Färber]

Am 09.07.2014 13:09, schrieb Anshul Makkar:
> Thanks. I got the point.

And for the record, the point is that the machine version on the
destination side needs to match the source side. So, if the default or
"pc" alias is used in 1.0, which resolves to pc-1.0, then it needs to be
pc-1.0, not pc-1.2. If an explicit machine name such as pc-0.15 was used
then that exact machine must be used on the destination as well.

Andreas

> On Wed, Jul 9, 2014 at 9:36 AM, Markus Armbruster <armbru@redhat.com> wrote:
>> Anshul Makkar <anshul.makkar@profitbricks.com> writes:
>>
>>> Hi,
>>>
>>> Yeah, I am aware of this option. But the point where I am concerned is
>>> that if Windows VM is running in QEMU 1.0 with pc-model 1.0 and then I
>>> upgrade the QEMU to 2.0 and I specify machine as pc-1.2, then Windows
>>> will see this as change in hardware and complain about the license.
>>
>> Works as designed.
>>
>>> Sorry, if my understanding is wrong here or i am missing something.
>>
>> Changing the machine type is the virtual equivalent of replacing the
>> motherboard.
> 


-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg

Re: [Qemu-devel] live migration + licensing issue.

[Eric Blake]

[-- Attachment #1: Type: text/plain, Size: 750 bytes --]

On 07/08/2014 03:10 PM, Anshul Makkar wrote:
> Hi,
> 
> Yeah, I am aware of this option. But the point where I am concerned is
> that if Windows VM is running in QEMU 1.0 with pc-model 1.0 and then I
> upgrade the QEMU to 2.0 and I specify machine as pc-1.2, then Windows
> will see this as change in hardware and complain about the license.

That's by design.  If you were running under qemu 1.0 with pc-model 1.0,
then when you upgrade to qemu 2.0, you must STILL use pc-model 1.0 (and
not pc-1.2) if you want your guest to see the same hardware as what the
older qemu was providing, and therefore avoid a relicensing issue.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 604 bytes --]

Re: [Qemu-devel] live migration + licensing issue.

[Anshul Makkar]

Yeah, but I think if we have to take advantage of live vertical
scaling (memory hotplug, memory hotunplug, cpu hotplug) then we need
to upgrade to pc model 1.2.

pc model 1.0 will be incompatible with qemu 2.0 wrt. LVS feature as
the bus architecture and the way how dimms are handled has changed
from pc model 1.0 in qemu 1.0 to pc model 2.0 (pc-i440fx-2.1) to qemu
2.0.

Yeah, true, if we have to avoid the licensing issue then we have to
use same PC model.

Anshul Makkar

On Fri, Jul 11, 2014 at 1:19 AM, Eric Blake <eblake@redhat.com> wrote:
> On 07/08/2014 03:10 PM, Anshul Makkar wrote:
>> Hi,
>>
>> Yeah, I am aware of this option. But the point where I am concerned is
>> that if Windows VM is running in QEMU 1.0 with pc-model 1.0 and then I
>> upgrade the QEMU to 2.0 and I specify machine as pc-1.2, then Windows
>> will see this as change in hardware and complain about the license.
>
> That's by design.  If you were running under qemu 1.0 with pc-model 1.0,
> then when you upgrade to qemu 2.0, you must STILL use pc-model 1.0 (and
> not pc-1.2) if you want your guest to see the same hardware as what the
> older qemu was providing, and therefore avoid a relicensing issue.
>
> --
> Eric Blake   eblake redhat com    +1-919-301-3266
> Libvirt virtualization library http://libvirt.org
>

Re: [Qemu-devel] live migration + licensing issue.

[Anshul Makkar]

Hi Andreas,

"the point is that the machine version on the destination side needs
to match the source side". I hope this is just to avoid the licensing
issue. Else, in all other circumstance, we can specify different pc
models while migrating from source to destination.

Anshul Makkar

On Wed, Jul 9, 2014 at 6:25 PM, Andreas Färber <afaerber@suse.de> wrote:
> Am 09.07.2014 13:09, schrieb Anshul Makkar:
>> Thanks. I got the point.
>
> And for the record, the point is that the machine version on the
> destination side needs to match the source side. So, if the default or
> "pc" alias is used in 1.0, which resolves to pc-1.0, then it needs to be
> pc-1.0, not pc-1.2. If an explicit machine name such as pc-0.15 was used
> then that exact machine must be used on the destination as well.
>
> Andreas
>
>> On Wed, Jul 9, 2014 at 9:36 AM, Markus Armbruster <armbru@redhat.com> wrote:
>>> Anshul Makkar <anshul.makkar@profitbricks.com> writes:
>>>
>>>> Hi,
>>>>
>>>> Yeah, I am aware of this option. But the point where I am concerned is
>>>> that if Windows VM is running in QEMU 1.0 with pc-model 1.0 and then I
>>>> upgrade the QEMU to 2.0 and I specify machine as pc-1.2, then Windows
>>>> will see this as change in hardware and complain about the license.
>>>
>>> Works as designed.
>>>
>>>> Sorry, if my understanding is wrong here or i am missing something.
>>>
>>> Changing the machine type is the virtual equivalent of replacing the
>>> motherboard.
>>
>
>
> --
> SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
> GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg

Re: [Qemu-devel] live migration + licensing issue.

[Paolo Bonzini]

Il 11/07/2014 12:14, Anshul Makkar ha scritto:
> Hi Andreas,
>
> "the point is that the machine version on the destination side needs
> to match the source side". I hope this is just to avoid the licensing
> issue. Else, in all other circumstance, we can specify different pc
> models while migrating from source to destination.

No, it is always necessary.

Think of it like this: you hibernate your workstation, change the 
motherboard and turn it on.  What chances would it have to work?  Of 
course changes in the machine types from one version to the next are 
_usually_ minor, but sometimes they can completely break the software. 
For example we've had a couple changes to the memory map over the years.

Paolo

Re: [Qemu-devel] live migration + licensing issue.

[Markus Armbruster]

[Top-quote moved to its rightful place; please do not top quote on
technical lists]

Anshul Makkar <anshul.makkar@profitbricks.com> writes:

> On Wed, Jul 9, 2014 at 6:25 PM, Andreas Färber <afaerber@suse.de> wrote:
>> Am 09.07.2014 13:09, schrieb Anshul Makkar:
>>> Thanks. I got the point.
>>
>> And for the record, the point is that the machine version on the
>> destination side needs to match the source side. So, if the default or
>> "pc" alias is used in 1.0, which resolves to pc-1.0, then it needs to be
>> pc-1.0, not pc-1.2. If an explicit machine name such as pc-0.15 was used
>> then that exact machine must be used on the destination as well.

> Hi Andreas,
>
> "the point is that the machine version on the destination side needs
> to match the source side". I hope this is just to avoid the licensing
> issue. Else, in all other circumstance, we can specify different pc
> models while migrating from source to destination.

You certainly can specify whatever machine type you want, but if you
specify different machine types on source and target of a migration, all
bets are off.

It could succeed if the stars align the right way.  It could break
obviously and immediately, leaving your machine running on the source.
It could migrate your machine to the destination successfully, then blow
up there right away, or some time later, taking down your machine.  It
could migrate successfully, but silently corrupt data.

Regardless of how it breaks, you get to keep the pieces.

Re: [Qemu-devel] live migration + licensing issue.

[Anshul Makkar]

On Fri, Jul 11, 2014 at 1:12 PM, Markus Armbruster <armbru@redhat.com> wrote:
> ly, leaving your machine running on the source.


Hmm. Got the point.

But as I mentioned above if we have to use live vertical scaling on
qemu 2.0, then pc-model 1.0 won't help (as the dimm handling and bus
handling has changed in pc-model 2.0 and qemu2.0 uses this changed
model).  QEMU 2.0 will only go with pc-model 2.0 wrt to LVS. Am I
correct here ?

Does the only solution is to shutdown the VM, upgrade qemu and then
start with new QEMU and new PC model .

Anshul Makkar

Re: [Qemu-devel] live migration + licensing issue.

[Eduardo Otubo]

On Fri, Jul 11, 2014 at 1:12 PM, Markus Armbruster <armbru@redhat.com> wrote:
> [Top-quote moved to its rightful place; please do not top quote on
> technical lists]
>
> Anshul Makkar <anshul.makkar@profitbricks.com> writes:
>
>> On Wed, Jul 9, 2014 at 6:25 PM, Andreas Färber <afaerber@suse.de> wrote:
>>> Am 09.07.2014 13:09, schrieb Anshul Makkar:
>>>> Thanks. I got the point.
>>>
>>> And for the record, the point is that the machine version on the
>>> destination side needs to match the source side. So, if the default or
>>> "pc" alias is used in 1.0, which resolves to pc-1.0, then it needs to be
>>> pc-1.0, not pc-1.2. If an explicit machine name such as pc-0.15 was used
>>> then that exact machine must be used on the destination as well.
>
>> Hi Andreas,
>>
>> "the point is that the machine version on the destination side needs
>> to match the source side". I hope this is just to avoid the licensing
>> issue. Else, in all other circumstance, we can specify different pc
>> models while migrating from source to destination.
>
> You certainly can specify whatever machine type you want, but if you
> specify different machine types on source and target of a migration, all
> bets are off.
>
> It could succeed if the stars align the right way.  It could break
> obviously and immediately, leaving your machine running on the source.
> It could migrate your machine to the destination successfully, then blow
> up there right away, or some time later, taking down your machine.  It
> could migrate successfully, but silently corrupt data.
>
> Regardless of how it breaks, you get to keep the pieces.

What you're saying is that there's no way to migrate (live or offline)
from Qemu 1.0/1.2 to 2.0 in a *safe way* whatever OS I'm running on
it?

-- 
Eduardo Otubo
ProfitBricks

Re: [Qemu-devel] live migration + licensing issue.

[Markus Armbruster]

Eduardo Otubo <eduardo.otubo@profitbricks.com> writes:

> On Fri, Jul 11, 2014 at 1:12 PM, Markus Armbruster <armbru@redhat.com> wrote:
>> [Top-quote moved to its rightful place; please do not top quote on
>> technical lists]
>>
>> Anshul Makkar <anshul.makkar@profitbricks.com> writes:
>>
>>> On Wed, Jul 9, 2014 at 6:25 PM, Andreas Färber <afaerber@suse.de> wrote:
>>>> Am 09.07.2014 13:09, schrieb Anshul Makkar:
>>>>> Thanks. I got the point.
>>>>
>>>> And for the record, the point is that the machine version on the
>>>> destination side needs to match the source side. So, if the default or
>>>> "pc" alias is used in 1.0, which resolves to pc-1.0, then it needs to be
>>>> pc-1.0, not pc-1.2. If an explicit machine name such as pc-0.15 was used
>>>> then that exact machine must be used on the destination as well.
>>
>>> Hi Andreas,
>>>
>>> "the point is that the machine version on the destination side needs
>>> to match the source side". I hope this is just to avoid the licensing
>>> issue. Else, in all other circumstance, we can specify different pc
>>> models while migrating from source to destination.
>>
>> You certainly can specify whatever machine type you want, but if you
>> specify different machine types on source and target of a migration, all
>> bets are off.
>>
>> It could succeed if the stars align the right way.  It could break
>> obviously and immediately, leaving your machine running on the source.
>> It could migrate your machine to the destination successfully, then blow
>> up there right away, or some time later, taking down your machine.  It
>> could migrate successfully, but silently corrupt data.
>>
>> Regardless of how it breaks, you get to keep the pieces.
>
> What you're saying is that there's no way to migrate (live or offline)
> from Qemu 1.0/1.2 to 2.0 in a *safe way* whatever OS I'm running on
> it?

No, what I'm saying is you need to use the same machine type on source
on destination.

If you don't specify one, you get the default.  If you run different
versions of QEMU on source and destination, their default machine type
may differ.

In that case, find the default machine type on the source (-M help shows
it), then start QEMU on the destination with that machine type.

Re: [Qemu-devel] live migration + licensing issue.

[Markus Armbruster]

Anshul Makkar <anshul.makkar@profitbricks.com> writes:

> On Fri, Jul 11, 2014 at 1:12 PM, Markus Armbruster <armbru@redhat.com> wrote:
>> ly, leaving your machine running on the source.
>
>
> Hmm. Got the point.
>
> But as I mentioned above if we have to use live vertical scaling on
> qemu 2.0, then pc-model 1.0 won't help (as the dimm handling and bus
> handling has changed in pc-model 2.0 and qemu2.0 uses this changed
> model).  QEMU 2.0 will only go with pc-model 2.0 wrt to LVS. Am I
> correct here ?
>
> Does the only solution is to shutdown the VM, upgrade qemu and then
> start with new QEMU and new PC model .

Assuming you actually value your data: yes.

Re: [Qemu-devel] live migration + licensing issue.

[Eduardo Otubo]

On Fri, Jul 11, 2014 at 2:19 PM, Markus Armbruster <armbru@redhat.com> wrote:
> Eduardo Otubo <eduardo.otubo@profitbricks.com> writes:
>
>> On Fri, Jul 11, 2014 at 1:12 PM, Markus Armbruster <armbru@redhat.com> wrote:
>>> [Top-quote moved to its rightful place; please do not top quote on
>>> technical lists]
>>>
>>> Anshul Makkar <anshul.makkar@profitbricks.com> writes:
>>>
>>>> On Wed, Jul 9, 2014 at 6:25 PM, Andreas Färber <afaerber@suse.de> wrote:
>>>>> Am 09.07.2014 13:09, schrieb Anshul Makkar:
>>>>>> Thanks. I got the point.
>>>>>
>>>>> And for the record, the point is that the machine version on the
>>>>> destination side needs to match the source side. So, if the default or
>>>>> "pc" alias is used in 1.0, which resolves to pc-1.0, then it needs to be
>>>>> pc-1.0, not pc-1.2. If an explicit machine name such as pc-0.15 was used
>>>>> then that exact machine must be used on the destination as well.
>>>
>>>> Hi Andreas,
>>>>
>>>> "the point is that the machine version on the destination side needs
>>>> to match the source side". I hope this is just to avoid the licensing
>>>> issue. Else, in all other circumstance, we can specify different pc
>>>> models while migrating from source to destination.
>>>
>>> You certainly can specify whatever machine type you want, but if you
>>> specify different machine types on source and target of a migration, all
>>> bets are off.
>>>
>>> It could succeed if the stars align the right way.  It could break
>>> obviously and immediately, leaving your machine running on the source.
>>> It could migrate your machine to the destination successfully, then blow
>>> up there right away, or some time later, taking down your machine.  It
>>> could migrate successfully, but silently corrupt data.
>>>
>>> Regardless of how it breaks, you get to keep the pieces.
>>
>> What you're saying is that there's no way to migrate (live or offline)
>> from Qemu 1.0/1.2 to 2.0 in a *safe way* whatever OS I'm running on
>> it?
>
> No, what I'm saying is you need to use the same machine type on source
> on destination.
>
> If you don't specify one, you get the default.  If you run different
> versions of QEMU on source and destination, their default machine type
> may differ.
>
> In that case, find the default machine type on the source (-M help shows
> it), then start QEMU on the destination with that machine type.
>

Let me rephrase that:
What you're saying is that there's no way to migrate (live or offline)
from pc-model 1.0/1.2 to pc-model 2.0 in a *safe way* whatever OS I'm
running on it?

As Anshul said, we want to migrate clients of our data center from
Qemu 1.0/1.2 to Qemu 2.0 to take advantage of live vertical scaling --
which implies in changing pc-model to 2.0. At least offline migration
you think it could be OK?

Regards,

-- 
Eduardo Otubo
ProfitBricks

Re: [Qemu-devel] live migration + licensing issue.

[Markus Armbruster]

Eduardo Otubo <eduardo.otubo@profitbricks.com> writes:

> On Fri, Jul 11, 2014 at 2:19 PM, Markus Armbruster <armbru@redhat.com> wrote:
>> Eduardo Otubo <eduardo.otubo@profitbricks.com> writes:
>>
>>> On Fri, Jul 11, 2014 at 1:12 PM, Markus Armbruster <armbru@redhat.com> wrote:
>>>> [Top-quote moved to its rightful place; please do not top quote on
>>>> technical lists]
>>>>
>>>> Anshul Makkar <anshul.makkar@profitbricks.com> writes:
>>>>
>>>>> On Wed, Jul 9, 2014 at 6:25 PM, Andreas Färber <afaerber@suse.de> wrote:
>>>>>> Am 09.07.2014 13:09, schrieb Anshul Makkar:
>>>>>>> Thanks. I got the point.
>>>>>>
>>>>>> And for the record, the point is that the machine version on the
>>>>>> destination side needs to match the source side. So, if the default or
>>>>>> "pc" alias is used in 1.0, which resolves to pc-1.0, then it needs to be
>>>>>> pc-1.0, not pc-1.2. If an explicit machine name such as pc-0.15 was used
>>>>>> then that exact machine must be used on the destination as well.
>>>>
>>>>> Hi Andreas,
>>>>>
>>>>> "the point is that the machine version on the destination side needs
>>>>> to match the source side". I hope this is just to avoid the licensing
>>>>> issue. Else, in all other circumstance, we can specify different pc
>>>>> models while migrating from source to destination.
>>>>
>>>> You certainly can specify whatever machine type you want, but if you
>>>> specify different machine types on source and target of a migration, all
>>>> bets are off.
>>>>
>>>> It could succeed if the stars align the right way.  It could break
>>>> obviously and immediately, leaving your machine running on the source.
>>>> It could migrate your machine to the destination successfully, then blow
>>>> up there right away, or some time later, taking down your machine.  It
>>>> could migrate successfully, but silently corrupt data.
>>>>
>>>> Regardless of how it breaks, you get to keep the pieces.
>>>
>>> What you're saying is that there's no way to migrate (live or offline)
>>> from Qemu 1.0/1.2 to 2.0 in a *safe way* whatever OS I'm running on
>>> it?
>>
>> No, what I'm saying is you need to use the same machine type on source
>> on destination.
>>
>> If you don't specify one, you get the default.  If you run different
>> versions of QEMU on source and destination, their default machine type
>> may differ.
>>
>> In that case, find the default machine type on the source (-M help shows
>> it), then start QEMU on the destination with that machine type.
>>
>
> Let me rephrase that:
> What you're saying is that there's no way to migrate (live or offline)
> from pc-model 1.0/1.2 to pc-model 2.0 in a *safe way* whatever OS I'm
> running on it?

Yes, where "migrate offline" is something like savevm / loadvm.

The only safe way to upgrade to a newer machine type is shutdown &
restart with new type.

> As Anshul said, we want to migrate clients of our data center from
> Qemu 1.0/1.2 to Qemu 2.0 to take advantage of live vertical scaling --
> which implies in changing pc-model to 2.0. At least offline migration
> you think it could be OK?

Changing the machine type is the virtual equivalent of replacing the
motherboard.  No safe way to pull that off without a reboot, I'm afraid.