From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:56143) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z32Jg-0005x3-Mz for qemu-devel@nongnu.org; Thu, 11 Jun 2015 09:14:48 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Z32Ja-00038i-3Y for qemu-devel@nongnu.org; Thu, 11 Jun 2015 09:14:43 -0400 Received: from mail-wi0-x234.google.com ([2a00:1450:400c:c05::234]:38153) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z32JZ-00038L-Th for qemu-devel@nongnu.org; Thu, 11 Jun 2015 09:14:38 -0400 Received: by wibdq8 with SMTP id dq8so9424857wib.1 for ; Thu, 11 Jun 2015 06:14:37 -0700 (PDT) Date: Thu, 11 Jun 2015 14:14:32 +0100 From: Stefan Hajnoczi Message-ID: <20150611131432.GE9425@stefanha-thinkpad.redhat.com> References: <1433776886-27239-1-git-send-email-vsementsov@virtuozzo.com> <20150610152756.GA17294@stefanha-thinkpad.redhat.com> <55796F7B.5000105@virtuozzo.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="GxcwvYAGnODwn7V8" Content-Disposition: inline In-Reply-To: <55796F7B.5000105@virtuozzo.com> Subject: Re: [Qemu-devel] [PATCH v2 RFC 0/8] block: persistent dirty bitmaps List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Vladimir Sementsov-Ogievskiy Cc: kwolf@redhat.com, qemu-devel@nongnu.org, Stefan Hajnoczi , den@openvz.org, pbonzini@redhat.com, jsnow@redhat.com --GxcwvYAGnODwn7V8 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jun 11, 2015 at 02:22:35PM +0300, Vladimir Sementsov-Ogievskiy wrot= e: > On 10.06.2015 18:27, Stefan Hajnoczi wrote: > >On Mon, Jun 08, 2015 at 06:21:18PM +0300, Vladimir Sementsov-Ogievskiy w= rote: > >>QCow2 header is extended by fields 'nb_dirty_bitmaps' and > >>'dirty_bitmaps_offset' like with snapshots. > >> > >>Proposed command line syntax is the following: > >> > >>-dirty-bitmap [option1=3Dval1][,option2=3Dval2]... > >Two questions: > > > >1. How does this code ensure that the dirty bitmap is consistent after > >crash/power failure? >=20 > It's not done yet. What about consistent ('dirty' is not very good for di= rty > bitmaps=3D) flag for every bitmap? Set it on save and unset on load.. Okay. The consistency issue is key to dirty bitmaps so it must be addressed before we merge patches. Other terms to describe the flag: "in_use" or "outdated" > > > >At the minimum, enabled dirty bitmaps must be discarded after > >crash/power failure if we cannot guarantee they are up-to-date. It's > >worse to rely on an outdated dirty bitmap than to detect failure and > >start afresh. > > > >2. How do persistent dirty bitmaps work with live migration? Remember > >there are two storage cases for live migration: shared storage (NAS or > >SAN) and non-shared storage (disk images must be copied over). > For now: > Only loaded bitmaps are migrated. I see. That is probably fine. > So, for shared image, all is ok: loaded bitmaps are migrated (in migratio= n, > if there is a bitmap with same name, size and granularity on destination, > then it will be transparently used as destination bitmap), not loaded > bitmaps are the same in the image. Code might be necessary to ensure that: 1. The source host does not store the bitmap after successful live migration handover. (It could overwrite new data with old data!) 2. The destination host does not discard an "in_use" bitmap when it opens the qcow2 file before migration handover. > For non-shared storage, not loaded bitmaps are not migrated at all. Hmm..= is > it bad? Looks like so. That's probably okay since loaded bitmaps are migrated. Non-shared storage migration only transfers the contents of attached disks, it does not transfer qcow2 internal snapshots, for example. So the current behavior is consistent with qcow2 non-shared storage semantics. --GxcwvYAGnODwn7V8 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJVeYm4AAoJEJykq7OBq3PI5M0H+QEToXxMl2MmEA6YXNSq52dh o6+o/+KfIKdMT/I0w24NNKbSQ63L36wN/wec2ouZg3fGqfnk8Mj+BcEzWMUpO8jr TcbmfMkrxB2f4LXKk6dCmHH53IvoHpbLiZeMTMTfXviw/G4h2REsJACYNltelAZ5 G5YnsNnCrbYktLDt+E+oOyXiPRDVImFGX4GkXDqhV7IZKYgbNiTJG/+tEEfel5FV HfezP3Wvy+piea0rcvLUcyNrKu/JyU++PUfaUnYtSrcd4m89W6ECEYYQIO9kLTyl SssIWchxAtatF46/jP9hKeexNxStZY4a/wsSwiPo8esh+szmQsygMSZapWGSxWc= =Uy+d -----END PGP SIGNATURE----- --GxcwvYAGnODwn7V8--