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

[Anton Kuchin]

On 26/01/2023 17:13, Stefan Hajnoczi wrote:
> On Thu, 26 Jan 2023 at 09:20, Anton Kuchin <antonkuchin@yandex-team.ru> wrote:
> > 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@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?
> It's unclear to me how the destination QEMU is able to connect to the
> vhost-user back-end while the source QEMU is still connected? I
> thought additional QEMU changes would be necessary to make migration
> handover work.
>
> Stefan

Oh, yes, that is exactly the part I'm checking right now: I was
testing the scenario when vm is saved to file and then restored from
file without host and destination running at the same time.