From nobody Mon Feb 9 12:12:07 2026 Delivered-To: importer@patchew.org Received-SPF: pass (zohomail.com: domain of redhat.com designates 207.211.31.81 as permitted sender) client-ip=207.211.31.81; envelope-from=libvir-list-bounces@redhat.com; helo=us-smtp-delivery-1.mimecast.com; Authentication-Results: mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of redhat.com designates 207.211.31.81 as permitted sender) smtp.mailfrom=libvir-list-bounces@redhat.com; dmarc=pass(p=none dis=none) header.from=redhat.com ARC-Seal: i=1; a=rsa-sha256; t=1593007691; cv=none; d=zohomail.com; s=zohoarc; b=dsb8HnKjz/VvNduQ2L8So46cQl3TkbQgQgp4mODO7TelaK+HJ+HKR3b3DWTu8Ac8xgHKKcY26rz0BlO0Sogy/IgL4ViJG9SwIkOZiRn2M7irehpeBJ3Qw6GIgWBckdFB0a/C3vE3mOnEYOvr26pKK0Xj0i5wjTWcsZ7ma8kaVCA= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1593007691; h=Content-Type:Content-Transfer-Encoding:Date:From:In-Reply-To:List-Subscribe:List-Post:List-Id:List-Archive:List-Help:List-Unsubscribe:MIME-Version:Message-ID:References:Sender:Subject:To; bh=f1nfJn/RGYHHR86by1pXshTXn0W+lSy3OmXSVg6o/48=; b=KrRoJ3D8BstfTCNrsX7oyIjp0yArBfGzjKl0LJZis1yY0I40YlfBZH4I/u7L96IkK6CMvv9gOUcLMzU7d6s0+uTMsXOVWKAI0ygRDwGcifRIJnosf3PDvXYsCdyH9GL3uJDJzFTkpkflj+WsE7qiUDFQfNOC82V9ikEmQEABQXA= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of redhat.com designates 207.211.31.81 as permitted sender) smtp.mailfrom=libvir-list-bounces@redhat.com; dmarc=pass header.from= (p=none dis=none) header.from= Return-Path: Received: from us-smtp-delivery-1.mimecast.com (us-smtp-1.mimecast.com [207.211.31.81]) by mx.zohomail.com with SMTPS id 1593007691286166.56111540826907; Wed, 24 Jun 2020 07:08:11 -0700 (PDT) Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-379-0Hx4xR10OLqTte0kIsYzHA-1; Wed, 24 Jun 2020 10:08:07 -0400 Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 1A9E3805EE5; Wed, 24 Jun 2020 14:08:01 +0000 (UTC) Received: from colo-mx.corp.redhat.com (colo-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.20]) by smtp.corp.redhat.com (Postfix) with ESMTPS id DB63A1002393; Wed, 24 Jun 2020 14:08:00 +0000 (UTC) Received: from lists01.pubmisc.prod.ext.phx2.redhat.com (lists01.pubmisc.prod.ext.phx2.redhat.com [10.5.19.33]) by colo-mx.corp.redhat.com (Postfix) with ESMTP id A04FA180954D; Wed, 24 Jun 2020 14:08:00 +0000 (UTC) Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) by lists01.pubmisc.prod.ext.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id 05OE7xVu017412 for ; Wed, 24 Jun 2020 10:07:59 -0400 Received: by smtp.corp.redhat.com (Postfix) id A87FA5BAEF; Wed, 24 Jun 2020 14:07:59 +0000 (UTC) Received: from speedmetal.redhat.com (unknown [10.40.208.23]) by smtp.corp.redhat.com (Postfix) with ESMTP id 1D4687F49D for ; Wed, 24 Jun 2020 14:07:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1593007690; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:list-id:list-help: list-unsubscribe:list-subscribe:list-post; bh=f1nfJn/RGYHHR86by1pXshTXn0W+lSy3OmXSVg6o/48=; b=AcW9vjhv9MlU2+D0Xf/DG28trGp5nQA/khyXppFlhzfhRpJHPsvDdeu7DNy6h5YO2uftPe /5KhUGvcfavaCIfQz3+Fp8CLjO3HOJd++U/QJQ+qSVNOudGMGJXE5mzv6FU0tOCMWwQBOh 4ZOkv7fNWm+wNAajhQZZx/qug9tfLdU= X-MC-Unique: 0Hx4xR10OLqTte0kIsYzHA-1 From: Peter Krempa To: libvir-list@redhat.com Subject: [PATCH 2/6] kbase: incrementalbackupinternals: Clarify language in snapshots section Date: Wed, 24 Jun 2020 16:07:49 +0200 Message-Id: <06897d2190bcf3d272f8293ed435b5a1790f33d9.1593007594.git.pkrempa@redhat.com> In-Reply-To: References: MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15 X-loop: libvir-list@redhat.com X-BeenThere: libvir-list@redhat.com X-Mailman-Version: 2.1.12 Precedence: junk List-Id: Development discussions about the libvirt library & tools List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: libvir-list-bounces@redhat.com Errors-To: libvir-list-bounces@redhat.com X-Scanned-By: MIMEDefang 2.84 on 10.5.11.22 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Transfer-Encoding: quoted-printable X-ZohoMail-DKIM: pass (identity @redhat.com) Content-Type: text/plain; charset="utf-8" Emphaisze what needs to happen and also that creating a snapshot doesn't create the appropriate bitmaps. Also mention that granularity is kept. Signed-off-by: Peter Krempa Reviewed-by: Eric Blake --- docs/kbase/incrementalbackupinternals.rst | 23 ++++++++++++----------- 1 file changed, 12 insertions(+), 11 deletions(-) diff --git a/docs/kbase/incrementalbackupinternals.rst b/docs/kbase/increme= ntalbackupinternals.rst index eada0d2935..dbef1e96f3 100644 --- a/docs/kbase/incrementalbackupinternals.rst +++ b/docs/kbase/incrementalbackupinternals.rst @@ -109,17 +109,18 @@ as ``base image``. The topmost overlay is the image which is being written to by the VM and i= s also described as the ``active`` layer or image. -Handling of bitmaps -------------------- - -Creating an external snapshot involves adding a new layer to the backing c= hain -on top of the previous chain. In this step there are no new bitmaps create= d by -default, which would mean that backups become impossible after this step. - -To prevent this from happening we need to re-create the active bitmaps in = the -new top/active layer of the backing chain which allows us to continue trac= king -the changes with same granularity as before and also allows libvirt to sti= tch -together all the corresponding bitmaps to do a backup across snapshots. +Handling of bitmaps during snapshots +------------------------------------ + +Creating an external snapshot involves adding a overlay on top of the prev= iously +active image. Libvirt requires that all ``block-dirty-bitmaps`` which corr= espond +to the checkpoint must be created in the new overlay before any write from= the +guest reaches the overlay to continue tracking which blocks are dirtied. + +Since there are no new bitmaps created by ``qemu`` or ``qemu-img`` by defa= ult +when creating an overlay, we need to re-create the appropriate (see below.) +bitmaps in the new overlay based on the previously active bitmaps in the a= ctive +image. The new bitmaps are created with the same granularity. After taking a snapshot of the ``vda`` disk from the example above placed = into ``vda-2.qcow2`` the following topology will be created: --=20 2.26.2