On Wed, Oct 08, 2025 at 05:26:13PM -0400, Peter Xu wrote:
> On Thu, Sep 04, 2025 at 04:27:39PM +0800, Zhang Chen wrote:
> > > I confess I didn't test anything on COLO but only from code observations
> > > and analysis. COLO maintainers: could you add some unit tests to QEMU's
> > > qtests?
> >
> > For the COLO part, I think remove the coroutines related code is OK for me.
> > Because the original coroutine still need to call the
> > "colo_process_incoming_thread".
>
> Chen, thanks for the comment. It's still reassuring.
>
> >
> > Hi Hailiang, any comments for this part?
>
> Any further comment on this series would always be helpful.
>
> It'll be also great if anyone can come up with a selftest for COLO. Now
> any new migration features needs both unit test and doc to get merged.
> COLO was merged earlier so it doesn't need to, however these will be
> helpful for sure to make sure COLO won't be easily broken.
Chen/Hailiang:
I may use some help from COLO side.
Just now, I did give it a shot with the current docs/COLO-FT.txt and it
didn't really work for me.
The cmdlines I used almost followed the doc, however I changed a few
things. For example, on secondary VM I added "file.locking=off" for drive
"parent0" because otherwise the "nbd-server-add" command will fail taking
the lock and it won't ever boot. Meanwhile I switched to socket netdev
from tap, in my case I only plan to run the COLO main routine, I hope
that's harmless too but let me know if it is a problem.
So below are the final cmdlines I used..
For primary:
bin=~/git/qemu/bin/qemu-system-x86_64
$bin -enable-kvm -cpu qemu64,kvmclock=on \
-m 512 -smp 1 -qmp stdio \
-device piix3-usb-uhci -device usb-tablet -name primary \
-netdev socket,id=hn0,listen=127.0.0.1:10000 \
-device rtl8139,id=e0,netdev=hn0 \
-chardev socket,id=mirror0,host=0.0.0.0,port=9003,server=on,wait=off \
-chardev socket,id=compare1,host=0.0.0.0,port=9004,server=on,wait=on \
-chardev socket,id=compare0,host=127.0.0.1,port=9001,server=on,wait=off \
-chardev socket,id=compare0-0,host=127.0.0.1,port=9001 \
-chardev socket,id=compare_out,host=127.0.0.1,port=9005,server=on,wait=off
\
-chardev socket,id=compare_out0,host=127.0.0.1,port=9005 \
-object filter-mirror,id=m0,netdev=hn0,queue=tx,outdev=mirror0 \
-object filter-redirector,netdev=hn0,id=redire0,queue=rx,indev=compare_out
\
-object filter-redirector,netdev=hn0,id=redire1,queue=rx,outdev=compare0 \
-object iothread,id=iothread1 \
-object
colo-compare,id=comp0,primary_in=compare0-0,secondary_in=compare1,outdev=compare_out0,iothread=iothread1
\
-drive
if=ide,id=colo-disk0,driver=quorum,read-pattern=fifo,vote-threshold=1,children.0.file.filename=./primary.qcow2,children.0.driver=qcow2
For secondary (testing locally, hence using 127.0.0.1 as primary_ip):
bin=~/git/qemu/bin/qemu-system-x86_64
primary_ip=127.0.0.1
$bin -enable-kvm -cpu qemu64,kvmclock=on -m 512 -smp 1 -qmp stdio \
-device piix3-usb-uhci -device usb-tablet -name secondary \
-netdev socket,id=hn0,connect=127.0.0.1:10000 \
-device rtl8139,id=e0,netdev=hn0 \
-chardev socket,id=red0,host=$primary_ip,port=9003,reconnect-ms=1000 \
-chardev socket,id=red1,host=$primary_ip,port=9004,reconnect-ms=1000 \
-object filter-redirector,id=f1,netdev=hn0,queue=tx,indev=red0 \
-object filter-redirector,id=f2,netdev=hn0,queue=rx,outdev=red1 \
-object filter-rewriter,id=rew0,netdev=hn0,queue=all \
-drive
if=none,id=parent0,file.filename=primary.qcow2,driver=qcow2,file.locking=off \
-drive
if=none,id=childs0,driver=replication,mode=secondary,file.driver=qcow2,top-id=colo-disk0,file.file.filename=secondary-active.qcow2,file.backing.driver=qcow2,file.backing.file.filename=secondary-hidden.qcow2,file.backing.backing=parent0
\
-drive
if=ide,id=colo-disk0,driver=quorum,read-pattern=fifo,vote-threshold=1,children.0=childs0
\
-incoming tcp:0.0.0.0:9998
I started secondary, then primary, run the suggested QMP commands on
secondary first, then the bunch of QMP commands on primary. I got below
error:
x1:colo $ ./primary.sh
qemu-system-x86_64: -chardev
socket,id=compare1,host=0.0.0.0,port=9004,server=on,wait=on: info: QEMU waiting
for connection on: disconnected:tcp:0.0.0.0:9004,server=on
{"QMP": {"version": {"qemu": {"micro": 50, "minor": 1, "major": 10}, "package":
"v10.1.0-1513-g94586867df"}, "capabilities": ["oob"]}}
VNC server running on ::1:5900
{"execute":"qmp_capabilities"}
{"return": {}}
{"execute": "human-monitor-command", "arguments": {"command-line": "drive_add
-n buddy
driver=replication,mode=primary,file.driver=nbd,file.host=127.0.0.2,file.port=9999,file.export=parent0,node-name=replication0"}}
{"return": ""}
{"execute": "x-blockdev-change", "arguments":{"parent": "colo-disk0", "node":
"replication0" } }
{"return": {}}
{"execute": "migrate-set-capabilities", "arguments": {"capabilities": [
{"capability": "x-colo", "state": true } ] } }
{"return": {}}
{"execute": "migrate", "arguments": {"uri": "tcp:127.0.0.2:9998" } }
{"return": {}}
{"timestamp": {"seconds": 1760996025, "microseconds": 483349}, "event": "STOP"}
x1:colo $ ./secondary.sh
{"QMP": {"version": {"qemu": {"micro": 50, "minor": 1, "major": 10}, "package":
"v10.1.0-1513-g94586867df"}, "capabilities": ["oob"]}}
VNC server running on ::1:5901
{"execute":"qmp_capabilities"}
{"return": {}}
{"execute": "migrate-set-capabilities", "arguments": {"capabilities": [
{"capability": "x-colo", "state": true } ] } }
{"return": {}}
{"execute": "nbd-server-start", "arguments": {"addr": {"type": "inet", "data":
{"host": "0.0.0.0", "port": "9999"} } } }
{"return": {}}
{"execute": "nbd-server-add", "arguments": {"device": "parent0", "writable":
true } }
{"return": {}}
{"timestamp": {"seconds": 1760996025, "microseconds": 695059}, "event":
"RESUME"}
qemu-system-x86_64: Can't receive COLO message: Input/output error
{"timestamp": {"seconds": 1760996025, "microseconds": 695369}, "event":
"COLO_EXIT", "data": {"mode": "secondary", "reason": "error"}}
Do you know what I missed? Or does it mean that COLO is broken?
Meanwhile, do you know if COLO still being used by anyone? I'm pretty sure
both Fabiano and myself are not looking after it.. I remember Dave used to
try it, but it might be a long time ago too.
Thanks,
--
Peter Xu
