Re: [PATCH V2] migration: file URI

[Peter Xu]

On Mon, Jun 12, 2023 at 03:39:34PM -0400, Steven Sistare wrote:
> On 6/12/2023 2:44 PM, Peter Xu wrote:
> > Hi, Steve,
> > 
> > On Wed, Jun 07, 2023 at 11:38:59AM -0700, Steve Sistare wrote:
> >> Extend the migration URI to support file:<filename>.  This can be used for
> >> any migration scenario that does not require a reverse path.  It can be 
> >> used
> >> as an alternative to 'exec:cat > file' in minimized containers that do not
> >> contain /bin/sh, and it is easier to use than the fd:<fdname> URI.  It can
> >> be used in HMP commands, and as a qemu command-line parameter.
> > 
> > I have similar question on the fixed-ram work,
> 
> Sorry, what is the "fixed-ram work"?

https://lore.kernel.org/all/20230330180336.2791-1-farosas@suse.de

It has similar requirement to migrate to a file, though slightly different
use case.

> 
> > on whether we should assume
> > the vm stopped before doing so.  Again, it leaves us space for
> > optimizations on top without breaking anyone.
> 
> I do not assume the vm is stopped.  The migration code will stop the vm
> in migration_iteration_finish.
> 
> > The other thing is considering a very busy guest, migration may not even
> > converge for "file:" URI (the same to other URIs) but I think that doesn't
> > make much sense to not converge for a "file:" URI.  The user might be very
> > confused too.
> 
> The file URI is mainly intended for the case where guest ram is backed by 
> shared memory 
> and preserved in place, in which case writes are not tracked and convergence 
> is not an
> issue.  If not shared memory, the user should be advised to stop the machine 
> first.
> I should document these notes in qemu-options and/or migration.json.

My question was whether we should treat "file:" differently from most of
other URIs.  It makes the URI slightly tricky for sure, but it also does
make sense to me because "file:" implies more than the rest URIs, where
we're sure about the consequence of the migration (vm stops), in that case
keeping vm live makes it less performant, and also weird.

It doesn't need to be special in memory type being shared, e.g. what if
there's a device that contains a lot of data to migrate in the future?
Assuming "shared memory will always migrate very fast" may not hold true.

Do you think it makes more sense to just always stop VM when migrating to
file URI?  Then if someone tries to restart the VM or cancel the migration,
we always do both (cancel migration, then start VM).

-- 
Peter Xu