This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


Re: LAST_CHECKPOINT and save/restore/migrate compatibility (was Re: [Xen

To: Shriram Rajagopalan <rshriram@xxxxxxxxx>
Subject: Re: LAST_CHECKPOINT and save/restore/migrate compatibility (was Re: [Xen-devel] [PATCH 3 of 4] libxc: provide notification of final checkpoint to restore end)
From: Ian Campbell <Ian.Campbell@xxxxxxxxxxxxx>
Date: Sat, 2 Apr 2011 09:13:10 +0100
Cc: George Dunlap <George.Dunlap@xxxxxxxxxxxxx>, BrendanCully <brendan@xxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Sat, 02 Apr 2011 01:15:36 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <068F4087-A4CD-4EB7-B752-780A663D1BC1@xxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Organization: Citrix Systems, Inc.
References: <AANLkTik=XfbVbDzEGb3KL-UyN3oWVBvkrj4t+G9Fj_hf@xxxxxxxxxxxxxx> <1301659093.27123.227.camel@xxxxxxxxxxxxxxxxxxxxxx> <068F4087-A4CD-4EB7-B752-780A663D1BC1@xxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
On Sat, 2011-04-02 at 04:57 +0100, Shriram Rajagopalan wrote:
> On 2011-04-01, at 6:58 AM, Ian Campbell <Ian.Campbell@xxxxxxxxxxxxx> wrote:

> > Is it the case that Remus only cares about checkpointing between like
> > versions of the toolstack?
> > 
> Can you please elaborate this statement ?

For standard suspend/resume or migration we support migrating from
version N to version N+1 (but not vice versa), to support upgrades.

In the case of Remus though are we interested in supporting a rolling
checkpoint from a version N system to a version N+1 fallback system? Or
is Remus only interested in supporting checkpoints between systems
running the same version of Xen? 

Bear in mind that if you did support N->N+1 checkpoints you wouldn't be
able to migrate the VM back after a failover...

FWIW I think George got to the bottom of the specific issue he was
seeing and that the LAST_CHECKPOINT thing was a red-herring, although
flipping the protocol to use a MORE_CHECKPOINTS schema perhaps makes
sense anyway.


Xen-devel mailing list