From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NFBsd-000371-1a for qemu-devel@nongnu.org; Mon, 30 Nov 2009 14:25:51 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NFBsY-0002zX-FE for qemu-devel@nongnu.org; Mon, 30 Nov 2009 14:25:50 -0500 Received: from [199.232.76.173] (port=51054 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NFBsX-0002yy-HC for qemu-devel@nongnu.org; Mon, 30 Nov 2009 14:25:45 -0500 Received: from fmmailgate01.web.de ([217.72.192.221]:56934) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NFBsW-0001dX-V6 for qemu-devel@nongnu.org; Mon, 30 Nov 2009 14:25:45 -0500 Message-ID: <4B141C2E.6020502@web.de> Date: Mon, 30 Nov 2009 20:25:34 +0100 From: Jan Kiszka MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH 00/23] block migration: Fixes, cleanups and speedups References: <20091130172119.22889.28114.stgit@mchn012c.ww002.siemens.net> <4B141038.2030909@codemonkey.ws> <5D82F732-EB1C-46D7-B179-33CD69732F12@irisa.fr> In-Reply-To: <5D82F732-EB1C-46D7-B179-33CD69732F12@irisa.fr> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig30E5F7E40E1A88BB00D57639" Sender: jan.kiszka@web.de List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Pierre Riteau Cc: Liran Schour , qemu-devel@nongnu.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig30E5F7E40E1A88BB00D57639 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Pierre Riteau wrote: > On 30 nov. 2009, at 19:34, Anthony Liguori wrote: >=20 >> Jan Kiszka wrote: >>> This series is a larger rework of the block migration support qemu >>> recently gained. Besides lots of code refactorings the major changes >>> are: >>> - Faster restore due to larger block sizes (even if the target disk i= s >>> unallocated) >>> - Off-by-one fixes in the block dirty tracking code >>> - Allow for multiple migrations (after cancellation or if migrating >>> into a backup image) >>> - Proper error handling >>> - Progress reporting fixes: report to monitor instead of stdout, repo= rt >>> sum of multiple disks >>> - Report disk migration progress via 'info migrate' >>> - Progress report during restore >>> >>> One patch is directly taken from Pierre Riteau queue [1] who happend = to >>> work on the some topic the last days, two more are derived from his >>> commits. >>> >>> These patches make block migration usable for us. Still, there are tw= o >>> more major improvements on my wish/todo list: >>> - Respect specified maximum migration downtime (will require tracking= >>> of the number of dirty blocks + some coordination with ram migratio= n) >>> - Do not transfere unallocated disk space (also for raw images, ie. a= dd >>> bdrv_is_allocated support for the latter) >>> >>> In an off-list chat, Liran additionally brought up the topic that RAM= >>> migration should not start too early so that we avoid re-transmitting= >>> dirty pages over and over again while the disk image is slowly beamed= >>> over. >>> >>> I hope we can join our efforts to resolve the open topics quickly, th= e >>> critical ones ideally before the merge window closes. >>> =20 >> That really needs to happen no later than the end of this week. >> >> So Pierre/Liran, what do you think about Jan's series? >> >> Regards, >> >> Anthony Liguori >=20 >=20 > I'm currently testing these patches. Here are a few issues I noticed, b= efore I forget about them. >=20 > - "migrate -d -b tcp:dest:port" works, but "migrate -b -d tcp:dest:port= " doesn't, although "help migrate" doesn't really specify ordering as imp= ortant. But anyway I think Liran is working on a new version of the comma= nd. Saw that too. I think the monitor commands simply do very primitive option parsing so far. Should be addressed if the final format comes with this issue as well. > - We use bdrv_aio_readv() to read blocks from the disk. This function i= ncrements rd_bytes and rd_ops, which are reported by "info blockstats". I= don't think this read operations should appear in VM activity, especiall= y if this interface is used by libvirt to report VM stats (and draw graph= s in virt-manager, etc.). Same for write stats. Ack. > - We may need to call bdrv_reset_dirty() _before_ sending the data, to = be sure the block is not rewritten in the meantime (maybe it's an issue o= nly with kvm?) Can you elaborate? Even in case of multi-threaded qemu, the iomutex should protect us here. > - I seem to remember that disk images with 0 size are now possible. I'm= afraid we will hit a divide by zero in this case: "progress =3D complete= d_sector_sum * 100 / block_mig_state.total_sector_sum;" Although I don't see their use, it should be handled gracefully, likely by skipping such disks. >=20 > Apart from that, it works quite fine. Still a few things to cleanup (e.= g. unused constants) but much better than before. > However, I haven't tested the incremental transfer support at all yet. = It's on my todo list. >=20 Jan --------------enig30E5F7E40E1A88BB00D57639 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iEYEARECAAYFAksUHDEACgkQitSsb3rl5xTY2gCgiV59jVFGnUqCXdkOt3tZ9drb kREAnRBSIzw9c+5jDMpIROAUtZzXe0VM =Gl0j -----END PGP SIGNATURE----- --------------enig30E5F7E40E1A88BB00D57639--