From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:34044) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XrlRN-0002f8-JH for qemu-devel@nongnu.org; Fri, 21 Nov 2014 05:27:55 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XrlRH-0005Cr-Ae for qemu-devel@nongnu.org; Fri, 21 Nov 2014 05:27:49 -0500 Received: from relay.parallels.com ([195.214.232.42]:41787) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XrlRH-0005As-2a for qemu-devel@nongnu.org; Fri, 21 Nov 2014 05:27:43 -0500 Message-ID: <546F139C.1050408@parallels.com> Date: Fri, 21 Nov 2014 13:27:40 +0300 From: Vladimir Sementsov-Ogievskiy MIME-Version: 1.0 References: <546A88DD.10006@redhat.com> <1416479664-3414-1-git-send-email-vsementsov@parallels.com> <546DC54A.2050701@parallels.com> <20141120113622.GB11224@stefanha-thinkpad.redhat.com> In-Reply-To: <20141120113622.GB11224@stefanha-thinkpad.redhat.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit 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: Stefan Hajnoczi Cc: famz@redhat.com, jsnow@redhat.com, qemu-devel@nongnu.org, den@parallels.com > 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. Hm. I'm afraid, it still will not be free. If bitmap is active, it's actual version is in memory. To migrate bitmap file like a disk image, we should start syncing it with every write to corresponding disk, doubling number of io. Moreover, we have normal dirty bitmaps, which have no name/file, do we migrate them? If, for example, the migration occurs when backup in progress? Active bitmaps should be migrated in the same way for persistent/named/normal bitmaps. I can't find in qemu source, is there bitmap migration? Or you are saying about migrating disabled bitmaps? Hm. We should sync bitmap file on bitmap_disable. Disabled persistent bitmap is just a static file ~30mb, we can easily migrate it without common procedure with cow or something like this.. Best regards, Vladimir On 20.11.2014 14:36, Stefan Hajnoczi wrote: > 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