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: Anthony Liguori
Subject: Re: [Qemu-devel] live migration between qemu-kvm 1.0 and 0.15
Date: Tue, 27 Mar 2012 11:39:27 -0500
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120310 Thunderbird/11.0

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

I would expect that migration works from:

qemu-0.15 -M 0.15   =>   qemu-1.1 -M 0.15

I'm okay if this fails gracefully:

qemu-1.1 -M 0.15    <=   qemu-0.15 -M 0.15

Regards,

Anthony Liguori


Jan





reply via email to

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