Re: [PATCH v3 1/1] vhost-user-fs: add migration type property

[Anton Kuchin]

On 01/03/2023 17:33, Michael S. Tsirkin wrote:
> On Tue, Feb 28, 2023 at 07:59:54PM +0200, Anton Kuchin wrote:
> > We can't rely here entirely on
> > destination to block this because if VM is migrated to file and then
> > can't be loaded by destination there is no way to fallback and resume
> > the source so we need to have some kind of blocker on source by default.
> So I commented about a fallback. IMO it's just orchestrator being silly:
> don't kill source qemu until you have made sure destination loaded the
> file, or re-load it, and all will be well.

I agree that it is always better to keep source alive until destination
is loaded and ready to take-off. But in some cases resources are limited
or strictly partitioned so we can't keep two VMs alive at the same time
so the bast option is to check all we need on the source to make sure
destination will run.
Off the top of my head host-size VM would need entire additional host to
migrate properly and lots of memory streaming that can cause huge downtime,
but if memory is in shmem local migration to update qemu can take as much
as just saving device state to file and running new qemu to load devices,
take-over memory and continue running guest.

> But a bigger issue that this highlights is simply that if migrating to
> file you have no idea at all where will the file be loaded.  Maybe some
> orchestrators know but I don't see how we can be sure all of them know.
> The only time where we know whether the file is loaded on the same host
> where it was saved is when we actually load it.

Yes. Migration to file requires orchestrator to be well aware of what
it is doing because file always contains only part of the state. This
is hard but sometimes there are no other good options.