From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:39230) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XrQ2L-0002xV-Bj for qemu-devel@nongnu.org; Thu, 20 Nov 2014 06:36:40 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XrQ2D-0005CM-Rx for qemu-devel@nongnu.org; Thu, 20 Nov 2014 06:36:33 -0500 Received: from mx1.redhat.com ([209.132.183.28]:50299) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XrQ2D-0005CA-Hj for qemu-devel@nongnu.org; Thu, 20 Nov 2014 06:36:25 -0500 Date: Thu, 20 Nov 2014 11:36:22 +0000 From: Stefan Hajnoczi Message-ID: <20141120113622.GB11224@stefanha-thinkpad.redhat.com> References: <546A88DD.10006@redhat.com> <1416479664-3414-1-git-send-email-vsementsov@parallels.com> <546DC54A.2050701@parallels.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="tjCHc7DPkfUGtrlw" Content-Disposition: inline In-Reply-To: <546DC54A.2050701@parallels.com> Subject: Re: [Qemu-devel] [PATCH v2] persistent dirty bitmap: add QDB file spec. List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Vladimir Sementsov-Ogievskiy Cc: famz@redhat.com, jsnow@redhat.com, qemu-devel@nongnu.org, den@parallels.com --tjCHc7DPkfUGtrlw Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Thu, Nov 20, 2014 at 01:41:14PM +0300, Vladimir Sementsov-Ogievskiy wrote: > Also, it may be better to make this as qcow2 extension. And bitmap will be > saved in separate qcow2 file, which will contain only the bitmap(s) and no > other data (no disk, no snapshots). I think you are on to something with the idea of making the persistent dirty bitmap itself a disk image. That way drive-mirror and other commands can be used to live migrate the dirty bitmap along with the guest's disks. This allows both QEMU and management tools to reuse existing code. (We may need to allow multiple block jobs per BlockDriverState to make this work but in theory that can be done.) There is a constraint if we want to get live migration for free: The bitmap contents must be accessible with bdrv_read() and bdrv_get_block_status() to skip zero regions. Putting the dirty bitmap into its own data structure in qcow2 and not accessible as a BlockDriverState bdrv_read() means custom code must be written to migrate the dirty bitmap. So I suggest putting the bitmap contents into a disk image that can be accessed as a BlockDriverState with bdrv_read(). The metadata (bitmap name, granularity, etc) doesn't need to be stored in the image file because management tools must be aware of it anyway. The only thing besides the data that really needs to be stored is the up-to-date flag to decide whether this dirty bitmap was synced cleanly. A much simpler format would do for that. Stefan --tjCHc7DPkfUGtrlw Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJUbdI2AAoJEJykq7OBq3PIPhIH/jaTbhKJ7mfwTZ9CUUkpF7LX kh/gUjDRYBr3gPNPcfsRPr7qAgbk1YwEM9cM65vpUgNd9giyQU1EbeW4nxgdb841 C9t3MkY2AugOH/ybRog2mRPtXCJMY3XLwW/HrvRvmnlz+QRAQ7UGeaLV7q8aAHfg agl3wD8Wt5FwF4cbrIWoQ4/nd/w1dmj+9GVPAqnkiYfCLzGKvX3VDR/VH4oAAsnN YElLjsdcMy9aOMsWTrfXsiDIezlCxdZ/6Ey9GZWl7Vm+9lY9FvLQd9a/TZEL8AH8 Kx6GjbtwTBrftdH7uW+TZdALXNIKcFweK8mIOq6dnSuaKQ/hnDmITj8xNb65exs= =5ha4 -----END PGP SIGNATURE----- --tjCHc7DPkfUGtrlw--