On Thu, Oct 16, 2025 at 07:51:42PM +0100, Daniel P. Berrangé wrote: > On Thu, Oct 16, 2025 at 02:40:58PM -0400, Peter Xu wrote: > > On Thu, Oct 16, 2025 at 12:23:35PM +0300, Vladimir Sementsov-Ogievskiy > > wrote: > > > On 16.10.25 11:32, Daniel P. Berrangé wrote: > > > > On Thu, Oct 16, 2025 at 12:02:45AM +0300, Vladimir Sementsov-Ogievskiy > > > > wrote: > > > > > 1. Remote migration: we can't reuse backends (files, sockets, host > > > > > devices), as > > > > > we are moving to another host. So, we don't enable > > > > > "backend-transfer". We don't > > > > > transfer the backend, we have to initialize new backend on another > > > > > host. > > > > > > > > > > 2. Local migration to update QEMU, with minimal freeze-time and > > > > > minimal > > > > > extra actions: use "backend-transfer", exactly to keep the backends > > > > > (vhost-user-server, TAP device in kernel, in-kernel vfio device > > > > > state, etc) > > > > > as is. > > > > > > > > > > 3. Local migration, but we want to reconfigure some backend, or switch > > > > > to another backend. We disable "backend-transfer" for one device. > > > > > > > > This implies that you're changing 'backend-transfer' against the > > > > device at time of each migration. > > > > > > > > This takes us back to the situation we've had historically where the > > > > behaviour of migration depends on global properties the mgmt app has > > > > set prior to the 'migrate' command being run. We've just tried to get > > > > away from that model by passing everything as parameters to the > > > > migrate command, so I'm loathe to see us invent a new way to have > > > > global state properties changing migration behaviour. > > > > > > > > This 'backend-transfer' device property is not really a device property, > > > > it is an indirect parameter to the 'migrate' command. > > > > I was not seeing it like that. > > > > I was treating per-device parameter to be a flag showing whether the device > > is capable of passing over FDs, which is more like a device attribute.
Whether a backend is technically capable of transfer shouldn't require a user specified property - there should be an internal API to query whether the current backend configuration is transferrable or not, based on the code implementation. Allowing a mgmt app to specify this can only lead to mistakes, because they don't know the internal constraints of the implementation. The mgmt app should only be concerned with whether they want to transfer a backend or not which is a time-of-use decision rather than launch time decision. With regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
