qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] live migration between qemu-kvm 1.0 and 0.15


From: Jan Kiszka
Subject: Re: [Qemu-devel] live migration between qemu-kvm 1.0 and 0.15
Date: Thu, 29 Mar 2012 17:53:50 +0200
User-agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv:1.8.1.12) Gecko/20080226 SUSE/2.0.0.12-1.1 Thunderbird/2.0.0.12 Mnenhy/0.7.5.666

On 2012-03-29 17:23, Anthony Liguori wrote:
> On 03/27/2012 12:42 PM, Jan Kiszka wrote:
>> On 2012-03-27 18:49, Anthony Liguori wrote:
>>> On 03/27/2012 11:46 AM, Avi Kivity wrote:
>>>> On 03/27/2012 06:39 PM, Anthony Liguori wrote:
>>>>>
>>>>> So, since we're approaching 1.1, we should really discuss release
>>>>> criteria for 1.1 with respect to live migration.  I'd prefer to avoid
>>>>> surprises in this release.
>>>>
>>>> Agree strongly.
>>>>
>>>>>
>>>>> My expectation is that migration works from:
>>>>>
>>>>> qemu-1.0 -M 1.0     =>      qemu-1.1 -M 1.1
>>>>
>>>> Why do you expect that?  Maybe you meant -M 1.0 at the end?
>>>
>>> Sorry, I did mean -M 1.0.
>>>
>>>>
>>>>> qemu-1.1 -M 1.0<=    qemu-1.1 -M 1.0
>>>>>
>>>>> I would expect that migration works from:
>>>>>
>>>>> qemu-0.15 -M 0.15   =>     qemu-1.1 -M 0.15
>>>>>
>>>>
>>>> Ack.
>>>>
>>>>> I'm okay if this fails gracefully:
>>>>>
>>>>> qemu-1.1 -M 0.15<=   qemu-0.15 -M 0.15
>>>>
>>>> RHEL has more stringent requirements (going back to its heavily patched
>>>> 0.12).  I think we should have the infrastructure that allow one to add
>>>> the hacks to make this work, even if we don't actually do the compat
>>>> work for the release (I think it's fine for qemu to support just one
>>>> version going back; and unreasonable to require it to go as far back as
>>>> RHEL).
>>>
>>> This is reasonable to me.
>>
>> Here is a draft to get things written in the old format. Totally
>> untested and likely borken (written in a hurry). I'll split up if it
>> works fine.
> 
> I don't really like this as a matter of principle.
> 
> Knowingly migrating when the result may be a broken guest is a bug, it's not 
> a 
> feature.
> 
> It's one thing if we're changing formats for other reasons, but if we're 
> changing the format to send what's effectively broken migration state, then 
> that's an evil thing to do.
> 
> Subsections are the compromise.  We send a subsection when we think migration 
> can work and fail gracefully when it can't.  Presumably there's a reason 
> we're 
> not using subsections here.

In this case (instance ID), it's actually not about a bug fix but a
consolidation of the vmstate format. So I think it's an exception,
though I don't like the code changes it requires as well.

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux



reply via email to

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