On Fri, Jan 16, 2026 at 6:59 AM Dr. David Alan Gilbert <[email protected]> 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. > > Lukas: Given COLO has a bunch of different features (i.e. the block > replication, the clever network comparison etc) do you know which ones > are used in the setups you are aware of? > > I'd guess the tricky part of a test would be the network side; I'm > not too sure how you'd set that in a test.
Hi Dave, For the COLO network test part we already have some qtest for that. The original COLO-proxy function decoupled into several QEMU netfilter modules: The filter-mirror/filter-redirector/filter-rewriter/colo-compare. Only the colo-compare is COLO specific one. COLO connect all the general modules with chardev socket to finish functions. Current status is we already have the qtest for filter-mirror/filter-redirector: like the qemu/tests/qtest/test-filter-mirror.c If this discussion ultimately dicides to retain COLO, I can cover COLO network test case. Thanks Chen > > Dave > > -- > -----Open up your eyes, open up your mind, open up your code ------- > / Dr. David Alan Gilbert | Running GNU/Linux | Happy \ > \ dave @ treblig.org | | In Hex / > \ _________________________|_____ http://www.treblig.org |_______/
