Stefan Hajnoczi <stefa...@gmail.com> wrote: > On Tue, Jan 24, 2023, 04:50 Dr. David Alan Gilbert <dgilb...@redhat.com> > wrote:
[...] >> > I checked how bad the situation is. libvhost-user currently enables >> > LOG_ALL by default. :( >> > >> > So I don't think the front-end can use LOG_ALL alone to determine >> > whether or not migration is supported by the back-end. >> > >> > There are several existing back-ends based on libvhost-user that have >> > no concept of reconnection or migration but report the LOG_ALL feature >> > bit. >> >> Ouch, yes that's messy. >> >> Going back to the original question; I don't think a command line flag >> will work though, because even for a given VM there's the possibility >> of some (local) migrations working but other (remote) migrations not >> working; so you don't know at the point you start the VM whether >> your migrations are going to work. >> > > The user or management tool should know which types of migration a > vhost-user-fs backend supports. That can be passed in as a per-device > parameter. > > Then a migration parameter can be used to distinguish between same host and > remote host migration? QEMU already distinguishes between pre-copy and > post-copy migration, so this can be thought of as yet another type of > migration. I was going to suggest this (my previous answer was after reading only the other part of the comments). What we have here is that this device has "three" states: - You can't migrate it to other host (now and the default behaviour) - You can migrate some of the backends if you are migrating in the same host (note, we don't know directly that we are migrating inside the same host, so I would agree to add _that_ migration capability, that is related to migration, and it makes sense for migration code and devices to know that is happening) - In the future, perhaps, you can migrate "always" some vhost-use-fs, that would be a property on my opinion. Later, Juan.
