On Tue, Dec 19, 2017 at 10:58:59AM +0000, Dr. David Alan Gilbert wrote: > * Peter Xu (pet...@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 <pet...@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 <dgilb...@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
