public inbox for kvm@vger.kernel.org
 help / color / mirror / Atom feed
From: Jan Kiszka <jan.kiszka@siemens.com>
To: Avi Kivity <avi@redhat.com>
Cc: Vasilis Liaskovitis <vasilis.liaskovitis@profitbricks.com>,
	"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	Juan Quintela <quintela@redhat.com>
Subject: Re: live migration between qemu-kvm 1.0 and 0.15
Date: Tue, 27 Mar 2012 18:22:52 +0200	[thread overview]
Message-ID: <4F71E95C.3070100@siemens.com> (raw)
In-Reply-To: <4F71E3CC.9070103@redhat.com>

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.

Jan

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

  reply	other threads:[~2012-03-27 16:23 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-03-27  8:55 live migration between qemu-kvm 1.0 and 0.15 Vasilis Liaskovitis
2012-03-27  9:55 ` Jan Kiszka
2012-03-27 15:59   ` Avi Kivity
2012-03-27 16:22     ` Jan Kiszka [this message]
2012-03-27 16:39       ` [Qemu-devel] " Anthony Liguori
2012-03-27 16:46         ` Avi Kivity
2012-03-27 16:49           ` Anthony Liguori
2012-03-27 17:42             ` Jan Kiszka
2012-03-29 15:23               ` Anthony Liguori
2012-03-29 15:53                 ` Jan Kiszka
2012-03-29 11:56         ` [Qemu-devel] " Jan Kiszka
2012-03-29 15:17           ` Avi Kivity
2012-03-29 15:21             ` Anthony Liguori
2012-03-29 15:25               ` Avi Kivity
2012-04-02 14:17         ` Markus Armbruster

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4F71E95C.3070100@siemens.com \
    --to=jan.kiszka@siemens.com \
    --cc=avi@redhat.com \
    --cc=kvm@vger.kernel.org \
    --cc=qemu-devel@nongnu.org \
    --cc=quintela@redhat.com \
    --cc=vasilis.liaskovitis@profitbricks.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox