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

[Jan Kiszka <jan.kiszka@siemens.com>]

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?

Jan

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