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 <antonkuc...@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
signature.asc
Description: PGP signature
