On Fri, Jan 16, 2026 at 09:46:43AM +0000, Daniel P. Berrangé wrote: > On Thu, Jan 15, 2026 at 10:59:47PM +0000, Dr. David Alan Gilbert wrote: > > * Peter Xu ([email protected]) wrote: > > > On Thu, Jan 15, 2026 at 10:49:29PM +0100, Lukas Straub wrote: > > > > Nack. > > > > > > > > This code has users, as explained in my other email: > > > > https://lore.kernel.org/qemu-devel/20260115224516.7f0309ba@penguin/T/#mc99839451d6841366619c4ec0d5af5264e2f6464 > > > > > > Please then rework that series and consider include the following (I > > > believe I pointed out a long time ago somewhere..): > > > > > > > > - Some form of justification of why multifd needs to be enabled for COLO. > > > For example, in your cluster deployment, using multifd can improve XXX > > > by YYY. Please describe the use case and improvements. > > > > That one is pretty easy; since COLO is regularly taking snapshots, the > > faster > > the snapshoting the less overhead there is. > > Also if we ever want to be able to deprecate the non-multifd migration, > then we need to ensure multifd migration has the super-set of functionality.
IIUC there's still long way to go for that, and I'm not yet sure if it will happen.. To achieve it, we'll need to first remove/deprecate multifd capability, because as long as it's there people can still set it to OFF.. But before that, we'll need to figure out how to do with features non-trivial to be supported, at least RDMA (it turns out we decided to keep RDMA, prior to this COLO discussion), and "fd:" URIs. I still don't know if we can justify nobody will be using some handy streaming tooling with QEMU migration, in that case it'll never work with multifd because multifd (even if channels=1) requires two sessions; there's always the main channel. So I'd put that aside when considering what we'd do with COLO. In that case IIUC COLO is the easy part if we really want to always use multifd. Thanks, -- Peter Xu
