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: Mon, 15 Jul 2013 15:24:59 +0100 Message-ID: <51E4063B.4010302@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> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1373543028.5453.180.camel@hastur.hellion.org.uk> 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 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) ~Andrew