From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cooper Subject: Re: [PATCH] tools/migrate: Fix regression when migrating from older version of Xen Date: Tue, 16 Jul 2013 10:32:36 +0100 Message-ID: <51E51334.3080503@citrix.com> References: <1373483987-32343-1-git-send-email-andrew.cooper3@citrix.com> <1373536530.5453.163.camel@hastur.hellion.org.uk> <51DE94D1.6070303@citrix.com> <1373543028.5453.180.camel@hastur.hellion.org.uk> <51E4063B.4010302@citrix.com> <1373967121.4663.24.camel@kazak.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1373967121.4663.24.camel@kazak.uk.xensource.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Ian Campbell Cc: Ian Jackson , Xen-devel List-Id: xen-devel@lists.xenproject.org On 16/07/13 10:32, Ian Campbell wrote: > On Mon, 2013-07-15 at 15:24 +0100, Andrew Cooper wrote: >> On 11/07/13 12:43, Ian Campbell wrote: >>> On Thu, 2013-07-11 at 12:19 +0100, Andrew Cooper wrote: >>>> On 11/07/13 10:55, Ian Campbell wrote: >>>>> On Wed, 2013-07-10 at 20:19 +0100, Andrew Cooper wrote: >>>>>> Commit 00a4b65f8534c9e6521eab2e6ce796ae36037774 Sep 7 2010 >>>>>> "libxc: provide notification of final checkpoint to restore end" >>>>>> broke migration from any version of Xen using tools from prior to that commit >>>>>> >>>>>> Older tools have no idea about an XC_SAVE_ID_LAST_CHECKPOINT, causing newer >>>>>> tools xc_domain_restore() to start reading the qemu save record, as >>>>>> ctx->last_checkpoint is 0. >>>>> Can the receive not distinguish the case where it is receiving a >>>>> checkpoint stream from a regular one? Either via some property of the >>>>> stream or the parameters with which it was called? >>>>> >>>>> ctx->last_checkpoint should (be made to) only matter if you are doing >>>>> check pointing and I think we can mandate that checking pointing is only >>>>> supported between like versions of Xen. TBH it's a bit odd to send the >>>>> LAST_CHECKPOINT in anon-checkpoint stream anyway, but what's done is >>>>> done. >>>>> >>>>> Ian. >>>> Sending LAST_CHECKPOINT is the only thing which has allowed normal >>>> migration to work since this regression. >>>> >>>> I cant find any way of distinguishing a normal vs checkpointed migrate >>>> from the stream alone. The save_callback->checkpoint function pointer >>>> may or may not be filled in by a toolstack, but is completely >>>> out-of-band as far as the migration stream is concerned. >>> I suppose your new last_generation-aware flag is similar to the "is a >>> checkpoint restore" lag which I was thinking of, but it somewhat easier >>> for the toolstack to know that it is receiving a checkpoint vs. normal >>> migration compared with magically knowing the version on the other end >>> of the connection. >>> >>> Ian. >>> >> So is this an indication of this patch being a good fix for the problem? >> (I guess this is a pseudo-ping given no specific objection) > If it implements the semantics I describe then all you need to do is > change the name. > > The reason I prefer a "incoming checkpointed stream" flag over a > "understands last checkpoint" is that the former is something the > toolstack knows about independently of the versions of Xen on either end > of the socket. > > Ian. > > Ok - I will respin to that effect. ~Andrew