[Virtio-fs] [PATCH] vhost-user-fs: add capability to allow migration

[Anton Kuchin]

On 25/01/2023 21:46, Stefan Hajnoczi wrote:
> On Sun, Jan 15, 2023 at 07:09:03PM +0200, Anton Kuchin wrote:
>> Now any vhost-user-fs device makes VM unmigratable, that also prevents
>> qemu update without stopping the VM. In most cases that makes sense
>> because qemu has no way to transfer FUSE session state.
>>
>> But we can give an option to orchestrator to override this if it can
>> guarantee that state will be preserved (e.g. it uses migration to
>> update qemu and dst will run on the same host as src and use the same
>> socket endpoints).
>>
>> This patch keeps default behavior that prevents migration with such devices
>> but adds migration capability 'vhost-user-fs' to explicitly allow migration.
>>
>> Signed-off-by: Anton Kuchin <antonkuchin at yandex-team.ru>
>> ---
>>   hw/virtio/vhost-user-fs.c | 25 ++++++++++++++++++++++++-
>>   qapi/migration.json       |  7 ++++++-
>>   2 files changed, 30 insertions(+), 2 deletions(-)
> Hi Anton,
> Sorry for holding up your work with the discussions that we had. I still
> feel it's important to agree on command-line and/or vhost-user protocol
> changes that will be able to support non-migratable, stateless
> migration/reconnect, and stateful migration vhost-user-fs back-ends. All
> three will exist.
>
> As a next step, could you share your code that implements the QEMU side
> of stateless migration?
>
> I think that will make it clearer whether a command-line option
> (migration capability or per-device) is sufficient or whether the
> vhost-user protocol needs to be extended.
>
> If the vhost-user protocol is extended then maybe no user-visible
> changes are necessary. QEMU will know if the vhost-user-fs backend
> supports migration and which type of migration. It can block migration
> in cases where it's not possible.
>
> Thanks,
> Stefan


Thank you, Stefan,

That's OK. The discussion is very helpful and showed me some parts
that should to be checked to make sure no harm is done by this feature.
I needed some time to step back, review my approach to this feature
with all valuable feedback and ideas that were suggested and check
what other backend implementations can or can't do.
I'll answer today the emails with questions that were addressed to me.

This is all the code that QEMU needs to support stateless migration.
Do you mean backend and/or orchestrator parts?

I'll think of how protocol extension can help us make this feature
transparent to users.