From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:46294) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZAMyS-0001vP-C5 for qemu-devel@nongnu.org; Wed, 01 Jul 2015 14:43:10 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZAMyR-0000SN-1v for qemu-devel@nongnu.org; Wed, 01 Jul 2015 14:43:08 -0400 Date: Wed, 1 Jul 2015 19:42:54 +0100 From: "Dr. David Alan Gilbert" Message-ID: <20150701184254.GG2137@work-vm> References: <20150619104953.GB9807@stefanha-thinkpad.redhat.com> <5584DEA8.80005@gmail.com> <20150624140755.GC2206@work-vm> <558B52EE.3000800@cn.fujitsu.com> <20150626190335.GN2186@work-vm> <559099E5.6080205@cn.fujitsu.com> <20150630190146.GE2142@work-vm> <55933BDC.40401@cn.fujitsu.com> <20150701081138.GA2137@work-vm> <5593A250.7090409@cn.fujitsu.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5593A250.7090409@cn.fujitsu.com> Subject: Re: [Qemu-devel] [Qemu-block] [PATCH COLO-Block v6 07/16] Add new block driver interface to connect/disconnect the remote target List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Wen Congyang Cc: Kevin Wolf , Fam Zheng , Wen Congyang , qemu block , Stefan Hajnoczi , Jiang Yunhong , Dong Eddie , qemu devel , Max Reitz , Lai Jiangshan , Gonglei , Stefan Hajnoczi , Paolo Bonzini , Yang Hongyang , zhanghailiang * Wen Congyang (wency@cn.fujitsu.com) wrote: > On 07/01/2015 04:11 PM, Dr. David Alan Gilbert wrote: > > * Wen Congyang (wency@cn.fujitsu.com) wrote: > >> On 07/01/2015 03:01 AM, Dr. David Alan Gilbert wrote: > >>> * Wen Congyang (wency@cn.fujitsu.com) wrote: > >>>> On 06/27/2015 03:03 AM, Dr. David Alan Gilbert wrote: > >>> > >>> > >>> > >>>>> Ah, I hadn't realised you could do that; so do you just do: > >>>>> > >>>>> migrate_set_parameter colo on > >>>>> migrate -d -b tcp:otherhhost:port > >>>>> > >>>>> How does the secondary know to feed that data straight into the disk without > >>>>> recording all the old data into the hidden-disk ? > >>>> > >>>> hidden disk and active disk will be made empty when starting block replication. > >>> > >>> Hmm, yes - I think I need to update to your current world; in the version > >>> from the end of May, I get a 'error while loading state for instance 0x0 of device 'block'' > >>> if I try to use migrate -d -b > >>> (the bdrv_write fails) > >> > >> Can you give me both primary and secondary qemu's command? I think the command line is wrong, > >> and disk migration fails. > >> > > > > Primary: > > > > ./try/bin/qemu-system-x86_64 -enable-kvm -nographic \ > > -boot c -m 4096 -smp 4 -S \ > > -name debug-threads=on -trace events=trace-file \ > > -netdev tap,id=hn0,script=$PWD/ifup-prim,\ > > downscript=no,colo_script=$PWD/qemu/scripts/colo-proxy-script.sh,colo_nicname=em4 \ > > -device e1000,mac=9c:da:4d:1c:b5:89,id=net-pci0,netdev=hn0 \ > > -drive if=virtio,driver=quorum,read-pattern=fifo,no-connect=on,\ > > cache=none,aio=native,\ > > children.0.file.filename=./bugzilla.raw,\ > > children.0.driver=raw,\ > > children.1.file.driver=nbd,\ > > children.1.file.host=ibpair,\ > > children.1.file.port=8889,\ > > children.1.file.export=colo1,\ > > children.1.driver=replication,\ > > children.1.mode=primary,\ > > children.1.ignore-errors=on > > Add id=nbd_target1 to primary disk option, and try it. Disk migration needs the same id to sync > the disk. Thank you! That worked nicely. The only odd thing was that the hidden disk on the secondary went upto ~2GB in size during the disk copy; (This is still on the version you posted at the end of may). I don't really understand why it was 2GB - the disk was 40GB, and qemu-img tells me that 2.6GB of it were used. Still, it would be good to avoid the overhead of going through the hidden disk on the secondary for the initial replication. Dave > Thanks > Wen Congyang > > > > > > > Secondary: > > > > ./try/bin/qemu-system-x86_64 -enable-kvm -nographic \ > > -boot c -m 4096 -smp 4 -S \ > > -name debug-threads=on -trace events=trace-file \ > > -netdev tap,id=hn0,script=$PWD/ifup-slave,\ > > downscript=no,colo_script=$PWD/qemu/scripts/colo-proxy-script.sh,colo_nicname=em4 \ > > -device e1000,mac=9c:da:4d:1c:b5:89,id=net-pci0,netdev=hn0 \ > > -drive if=none,driver=raw,file=bugzilla.raw,id=nbd_target1,cache=none,aio=native \ > > -drive if=virtio,driver=replication,mode=secondary,export=colo1,throttling.bps-total-max=70000000,\ > > file.file.filename=/run/colo-active-disk.qcow2,\ > > file.driver=qcow2,\ > > file.backing_reference.drive_id=nbd_target1,\ > > file.backing_reference.hidden-disk.file.filename=/run/colo-hidden-disk.qcow2,\ > > file.backing_reference.hidden-disk.driver=qcow2,\ > > file.backing_reference.hidden-disk.allow-write-backing-file=on \ > > -incoming tcp:0:8888 > > > > > > Thanks, > > > > Dave > > > >>>>>> If the user uses mirror job, we don't cancel the mirror job now. > >>>>> > >>>>> It would be good to get it to work with mirror, that seems preferred these > >>>>> days to the old block migration. > >>>> > >>>> In normal migration, is mirror job created and cancelled by libvirt? > >>> > >>> Yes, I think so; you should be able to turn on full logging on libvirt and > >>> watch the qmp commands it sends. > >> > >> Supporting mirror job in my TODO list now. But I think we should focus the basci function now. > >> > >> Thanks > >> Wen Congyang > >> > >>> > >>> Dave > >>> > >>> -- > >>> Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK > >>> . > >>> > >> > > -- > > Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK > > . > > > -- Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK