qemu-devel
[Top][All Lists]
Advanced

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

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


From: Markus Armbruster
Subject: Re: [Qemu-devel] live migration + licensing issue.
Date: Fri, 11 Jul 2014 14:41:53 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux)

Eduardo Otubo <address@hidden> writes:

> On Fri, Jul 11, 2014 at 2:19 PM, Markus Armbruster <address@hidden> wrote:
>> Eduardo Otubo <address@hidden> writes:
>>
>>> On Fri, Jul 11, 2014 at 1:12 PM, Markus Armbruster <address@hidden> wrote:
>>>> [Top-quote moved to its rightful place; please do not top quote on
>>>> technical lists]
>>>>
>>>> Anshul Makkar <address@hidden> writes:
>>>>
>>>>> On Wed, Jul 9, 2014 at 6:25 PM, Andreas Färber <address@hidden> 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.



reply via email to

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