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

[Avi Kivity]

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).

-- 
error compiling committee.c: too many arguments to function