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

[Anthony Liguori <anthony@codemonkey.ws>]

On 03/29/2012 10:17 AM, Avi Kivity wrote:
> On 03/29/2012 01:56 PM, Jan Kiszka wrote:
>> On 2012-03-27 18:39, Anthony Liguori wrote:
>>> On 03/27/2012 11:22 AM, Jan Kiszka wrote:
>>>> On 2012-03-27 17:59, Avi Kivity wrote:
>>>>> On 03/27/2012 11:55 AM, Jan Kiszka wrote:
>>>>>> On 2012-03-27 10:55, Vasilis Liaskovitis wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> is live migration between qemu-kvm stable-0.15 and stable-1.0 trees possible?
>>>>>>> When I live migrate a VM from 1.0 to 0.15, the destination side 0.15 qemu-kvm
>>>>>>> exits with:
>>>>>>> (qemu) Unknown savevm section or instance 'i8259' 0
>>>>>>>
>>>>>>> That's expected, since commit "i8259:convert to qdev" 747c70af78f7088f182c87e683bdf847beead1e4
>>>>>>> introduces the i8259 device in the qdev tree.
>>>>>>>
>>>>>>> The other direction (live migrate from 0.15.1 to 1.0.0) seems to work fine.
>>>>>>> Are any other issues expected in this direction?
>>>>>>>
>>>>>>> The vmstate for i8259 has not changed between these trees afaict. If the
>>>>>>> qdev-ified i8259 is reverted from stable-1.0 tree (to restore live-migration
>>>>>>> compatibility between the versions), would you expect problems?
>>>>>>
>>>>>> The legacy instance IDs used in old versions are not written out by
>>>>>> newer ones. They are just accepted on reading to allow moving forward.
>>>>>> There are more devices in the tree that used those instance IDs, not
>>>>>> only the i8259. Reverting the qdev conversion may reactivate backward
>>>>>> migratability for 1.0->0.15 (unless there are others as well). But that
>>>>>> will definitely be over after 1.1 as inrevertible code depends on the
>>>>>> qdev conversion.
>>>>>
>>>>> Is this true even for -M pc-0.15?
>>>>
>>>> Yes. Alias IDs enable modeling according to qdev (back then) for devices
>>>> that wrote oddly numbered states in the past and porting them over to
>>>> the new format. Adding some compat write-out mode would probably be
>>>> feasible but would also require some thoughts and quite a bit work to
>>>> integrate this cleanly in vmstate.
>>>>
>>>> I guess this just remained unnoticed because the introduction of the
>>>> alias ID concept and first conversions happened at a time when lots of
>>>> devices increased their vmstate version anyway.
>>>
>>> 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.
>>>
>>> My expectation is that migration works from:
>>>
>>> qemu-1.0 -M 1.0     =>     qemu-1.1 -M 1.1
>>> qemu-1.1 -M 1.0<=    qemu-1.1 -M 1.0
>>
>> Besides the instance ID thing, I found two further blockers:
>>
>>   - kvm-tpr-op (kvmvapic), easy to disable in non-1.1 machines
>>
>>   - vmstate fix for i8254 which involved a version bump from 2 to 3.
>>     That is actually now compatible with qemu-kvm and should not cause
>>     troubles there. But it breaks the backward-migration scenario for
>>     QEMU. I have no good idea how to resolve this while pleasing all
>>     consumers we care about. Any suggestions?
>
> Option 1: make -M old force an old vmstate to be written out.  Sounds
> like a generally useful thing.
> Option 2: ask those consumers to issue updates that bring their code up
> to version 3.  Require fully updated qemus on both sides.  Easy to
> achieve, result is less flexible but reasonable IMO (especially with a
> long lead time, which we have).

I prefer Option 2 presuming the bug is a legitimate bug fix.

If it couldn't be done as a subsection, then there's really no choice IMHO.

Regards,

Anthony Liguori

>