Re: [PATCH RFC 0/9] migration: Threadify loadvm process

[Lukas Straub <lukasstraub2@web.de>]

[-- Attachment #1: Type: text/plain, Size: 7031 bytes --]

On Mon, 20 Oct 2025 17:41:30 -0400
Peter Xu <peterx@redhat.com> wrote:

> 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
> 

Hi Peter,
You have to use -incoming defer and enable x-colo on the
secondary side before starting migration.

And primary.qcow2 should be a separate image (with same content) for
each qemu instance.

Regards,
Lukas


> 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,
> 


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]