From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:52818) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SXbM5-0005C6-Fd for qemu-devel@nongnu.org; Thu, 24 May 2012 12:57:43 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SXbLz-0002sE-0J for qemu-devel@nongnu.org; Thu, 24 May 2012 12:57:41 -0400 Received: from mx1.redhat.com ([209.132.183.28]:45232) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SXbLy-0002qx-Nt for qemu-devel@nongnu.org; Thu, 24 May 2012 12:57:34 -0400 Message-ID: <4FBE6861.2040503@redhat.com> Date: Thu, 24 May 2012 10:57:05 -0600 From: Eric Blake MIME-Version: 1.0 References: <4FB6821A.1080902@redhat.com> <4FBE3A89.8020702@redhat.com> In-Reply-To: <4FBE3A89.8020702@redhat.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enig01618D4C60300CBF6D3BB788" Subject: Re: [Qemu-devel] Block job commands in QEMU 1.2 [v2, including support for replication] List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: Kevin Wolf , Luiz Capitulino , qemu-devel , Ori Mamluk , Stefan Hajnoczi This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig01618D4C60300CBF6D3BB788 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable On 05/24/2012 07:41 AM, Paolo Bonzini wrote: > changes from v1: > - added per-job iostatus > - added description of persistent dirty bitmap >=20 > The same content is also at > http://wiki.qemu.org/Features/LiveBlockMigration/1.2 >=20 > * query-block-jobs: BlockJobInfo gets two new fields, paused and > io-status. The job-specific iostatus is completely separate from the > block device iostatus. Is it still true that for mirror jobs, whether we are mirroring is still determined by whether 'len'=3D=3D'offset'? > * drive-mirror: activates mirroring to a second block device (optionall= y > creating the image on that second block device). Compared to the > earlier versions, the "full" argument is replaced by an enum option > "sync" with three values: >=20 > - top: copies data in the topmost image to the destination >=20 > - full: copies data from all images to the destination >=20 > - dirty: copies clusters that are marked in the dirty bitmap to the > destination (see below) Different, but at least RHEL used the name __com.redhat_drive-mirror, so libvirt can cope with the difference. >=20 >=20 > * block-job-complete: force completion of mirroring and switching of th= e > device to the target, not related to the rest of the proposal. > Synchronously opens backing files if needed, asynchronously completes > the job. Can this be made part of a 'transaction'? Likewise, can 'block-job-cancel' be made part of a 'transaction'? Having those two commands transactionable means that you could copy multiple disks at the same point in time (block-job-cancel) or pivot multiple disks leaving the former files consistent at the same point in time (block-job-complete). It doesn't have to be done in the first round, but we should make sure we are not precluding this for future growth. Also, for the purposes of copying but not pivoting, you only have a safe copy if 'len'=3D=3D'offset' at the time of the cancel. But now that you = are adding the possibility of mirroring reverting to copying, there is a race where I can probe and see that we are in mirroring, then issue a 'block-job-cancel' to affect a copy operation, but in the meantime things reverted, and the cancel ends up leaving me with an incomplete copy. Maybe 'block-job-complete' should be given an optional boolean parameter; by default or if the parameter is true, we pivot, but if false, then we do the same as 'block-job-cancel' to affect a safe copy if we are in mirroring, while erroring out if we are not in mirroring, leaving 'block-job-cancel' as a way to always cancel a job but no longer a safe way to guarantee a copy operation. > Persistent dirty bitmap > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > A persistent dirty bitmap can be used by management for two reasons. > When mirroring is used for continuous replication of storage, to record= > I/O operations that happened while the replication server is not > connected or unavailable. When mirroring is used for storage migration= , > to check after a management crash whether the VM must be restarted with= > the source or the destination. Is there a particular file format for the dirty bitmap? Is there a header, or is it just straight bitmap, where the size of the file is an exact function of size of the file that it maps? >=20 > If management crashes between (6) and (7), it can examine the dirty > bitmap on disk. If it is all-zeros, Obviously, this would be all-zeros in the map portion of the file, any header portion would not impact this. > management can restart the virtual > machine with /mnt/dest/diskname.img. If it has even a single zero bit,= s/zero/non-zero/ > management can restart the virtual machine with the persistent dirty > bitmap enabled, and later issue again a drive-mirror command to restart= > from step 4. >=20 > Paolo >=20 --=20 Eric Blake eblake@redhat.com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --------------enig01618D4C60300CBF6D3BB788 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Public key at http://people.redhat.com/eblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBCAAGBQJPvmhhAAoJEKeha0olJ0NqG3cIAIc+0juOJbeRdYBh1lRP/Fpi b5lQx6uVhedawKcCuX74EqVH4DiUMimszCLq3YXdP/xxQJKVYdbhe7BkfCL439GH CWfkrysrA0tpYqExJEA4ztTw8LH/39uUB5Vk5nSnRuBIRnpuRklFW0XvRqKKwjMF +whSZ1mnSFEAa8wxgKCvLG3i+runz1yyGeh0TAdvSSG0rj1y9dzLaqafQ1x8BCl6 Z7rj76WkTbAY2/mo2IFFUj/kXWjb2gBdm1fsbCj2jx8IyijWqaCL7DYalN063AIA NPuMEHA9M6ql5aZebjR14ioUQuZIuLGgiQfTfQhlITPiz2qY+6JwaEkYsDANLkA= =QOsG -----END PGP SIGNATURE----- --------------enig01618D4C60300CBF6D3BB788--