Re: [Qemu-devel] [PATCH v5 26/28] migration: allow migrate_cancel to pause postcopy

[Peter Xu <peterx@redhat.com>]

On Tue, Dec 19, 2017 at 10:58:59AM +0000, Dr. David Alan Gilbert wrote:
> * Peter Xu (peterx@redhat.com) wrote:
> > It was allowed in the past to even cancel a postcopy migration, but it
> > does not really make sense, and no one should be using it, since
> > cancelling a migration during postcopy means crashing the VM at no time.
> > 
> > Let's just use re-use this command as a way to pause the postcopy
> > migration when we detected that we are in postcopy migration.  This can
> > be used when we want to trigger the postcopy recovery manually.
> > 
> > Signed-off-by: Peter Xu <peterx@redhat.com>
> 
> Yes, OK, this is a little odd without having any flags or anything, but
> it's essentially the saem reason that cancel exists - to stop a
> migration we know that's broken for some reason.
> 
> (I could argue whether this should be special cased in migrate_fd_cancel
> instead, but that's just a preference).
> 
> 
> Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com>

Firstly, thanks for the r-b.

Now after knowing your iptable test, I think we reached a consensus
that we need to provide a command (for example, reuse migrate-cancel)
to allow destination to shutdown its incoming migration port too.  At
the same time, if we want to make sure the command can always work on
destination, we'd better also let that command to be OOB-capable.

However I'm not sure whether I can let migrate-cancel be OOB-capable
since recently we added bdrv_invalidate_cache_all() into
migrate_fd_cancel().  That invalidation needs some mutex which might
block.  I don't know whether it means migrate-cancel will no longer be
suitable as an OOB command now.

So, maybe now I can do this: firstly, drop this patch; then add a new
command to do the shutdown explicitly (allow either src/dst to
shutdown its migration fd) and keep migrate-cancel untouched. In that
case, I can make sure the new command will be OOB-compatible.

What do you think?

-- 
Peter Xu