On Mon, Feb 09, 2026 at 08:23:29 +0000, Tejus GK wrote: > > > > On 2 Feb 2026, at 3:29 PM, Tejus GK <[email protected]> wrote: > > > > Libvirt supports FD-based live migrations in the form of tunnelled > > migrations. However, this isn't as performant as of now, since it > > involves extra copies.· > > > > This patchset proposes adding support for externally provided file > > descriptors for live migration. By allowing the client to supply the > > migration FD directly, the extra copy can be avoided, improving overall > > migration performance. > > > > The intent is to gather early feedback on the approach and its > > feasibility. Comments, concerns, and suggestions are very welcome :) > > > > V2: > > 1. Removed the approach of introducing a new FD passing API and instead > > reuse the virDomainFDAssociate API along with a dummy VM on the > > destination > > host. > > 2. Introduced a new virDomainMigrate parameter, VIR_MIGRATE_PARAM_FD_SET. > > > > > > Tejus GK (2): > > qemu: support incoming "fd" uri > > qemu: add support for fd based live migrations > > > > include/libvirt/libvirt-domain.h | 14 +++ > > src/qemu/qemu_driver.c | 24 +++-- > > src/qemu/qemu_migration.c | 174 +++++++++++++++++++++++++------ > > src/qemu/qemu_migration.h | 3 + > > 4 files changed, 178 insertions(+), 37 deletions(-) > > > > -- > > 2.43.7 > > > > Hi all, > > A gentle ping on this patch-series :)
The use of FD-passing in this series looks mostly sane to me. It's weird that the FD is labelled with the image label though. But as I've seen today while reviewing a different series that may make sense to me. This series will need to get rebased though as the virStorageSourceFDTuple was renamed today. It's just the type name, so nothing complex should be needed. In addition I've noticed that VIR_MIGRATE_PARAM_FD_SET is not implemented in virsh. You should add that. For the implementation into migration code I'll have to defer to Jiri as it's his domain. I think the best approach will be to resend the fixed version.
