From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:41798) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z30ZL-0008FB-Vt for qemu-devel@nongnu.org; Thu, 11 Jun 2015 07:22:48 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Z30ZI-0004GU-LR for qemu-devel@nongnu.org; Thu, 11 Jun 2015 07:22:47 -0400 Received: from mx2.parallels.com ([199.115.105.18]:51655) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z30ZI-0004GK-FO for qemu-devel@nongnu.org; Thu, 11 Jun 2015 07:22:44 -0400 Message-ID: <55796F7B.5000105@virtuozzo.com> Date: Thu, 11 Jun 2015 14:22:35 +0300 From: Vladimir Sementsov-Ogievskiy MIME-Version: 1.0 References: <1433776886-27239-1-git-send-email-vsementsov@virtuozzo.com> <20150610152756.GA17294@stefanha-thinkpad.redhat.com> In-Reply-To: <20150610152756.GA17294@stefanha-thinkpad.redhat.com> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit 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: Stefan Hajnoczi Cc: kwolf@redhat.com, qemu-devel@nongnu.org, pbonzini@redhat.com, den@openvz.org, jsnow@redhat.com On 10.06.2015 18:27, Stefan Hajnoczi wrote: > On Mon, Jun 08, 2015 at 06:21:18PM +0300, Vladimir Sementsov-Ogievskiy wrote: >> 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=val1][,option2=val2]... > Two questions: > > 1. How does this code ensure that the dirty bitmap is consistent after > crash/power failure? It's not done yet. What about consistent ('dirty' is not very good for dirty bitmaps=) flag for every bitmap? Set it on save and unset on load.. > > 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. So, for shared image, all is ok: loaded bitmaps are migrated (in migration, 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. For non-shared storage, not loaded bitmaps are not migrated at all. Hmm.. is it bad? Looks like so. I can add a function to load all not loaded bitmaps from the image in disabled state. Then variants: 1) call it automatically before migration 2) add a cmd parameter, to load 'all other bitmaps' in disabled state 3) always load all available bitmaps. (1), (3) are bad I think, because bitmaps may be stored in separate file (especially for non-qcow2 images), and, if this file is not mentioned in cmd (all bitmap are not loaded), then there is no possibility of migrating them automatically. -- Best regards, Vladimir * now, @virtuozzo.com instead of @parallels.com. Sorry for this inconvenience.