On Thu, 26 Jan 2023 at 09:20, Anton Kuchin <antonkuc...@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 <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 > > > 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
