Re: [Qemu-devel] [PATCH 1/3] block: prohibit migration during BlockJobs

[Kevin Wolf]

Am 02.10.2015 um 20:17 hat John Snow geschrieben:
> On 10/01/2015 02:03 PM, Paolo Bonzini wrote:
> > On 01/10/2015 18:34, John Snow wrote:
> >> Unless we can prove this to be safe for specific cases,
> >> the default should be to prohibit migration during BlockJobs.
> > 
> > Block jobs do not affect the current block, only other block device,
> > hence they *are* safe for migration.
> > 
> 
> Can you elaborate for me here?
> 
> > What you want, I think, is the target not to be garbage when migration
> > ends.  Based on this you can block specific cases, namely mirror which
> > you already do allow (patch 2) and backup except for sync='none'.
> > 
> > Paolo
> 
> It would be nice if the target wasn't garbage, yes :)
> 
> I allow mirror in specific circumstances -- you can't start a mirror,
> but if an existing mirror has hit the sync phase, that's OK.
> 
> I can try to do a more exhaustive audit of what should and should not
> work, but my thought was "guilty before proven innocent."

I think I've come to the conclusion that qemu can't even know in all
cases (particularly mirroring) because it depends on what the resulting
image is used for.

If we mirror in order to do a live storage migration, then obviously it
needs to run during migration. In this case, your restriction "only in
sync phase" seems to be right.

If we mirror for some other reason, the mirroring job should probably
continue running on the destination host. The management tool can set up
the destination accordingly, but if it doesn't, the job is silently
cancelled. The point is that qemu (even more on the source host) doesn't
know which case is true, so rejecting the migration seems wrong.

If we do commit or stream, the job is silently cancelled and must be
restarted on the destination host. It's the same case as above.

All (or most) of the restarting jobs on the destination doesn't come for
free, we usually repeat some useless work that the source host had
already done. That's not a reason to reject migrations, just cost for
the user to consider before they start migration.

So in the end, I'm not sure how much qemu can actually do here.

Kevin