[PATCH 2/6] kbase: incrementalbackupinternals: Clarify language in snapshots section

Peter Krempa posted 6 patches 5 years, 7 months ago
[PATCH 2/6] kbase: incrementalbackupinternals: Clarify language in snapshots section
Posted by Peter Krempa 5 years, 7 months ago
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 <pkrempa@redhat.com>
---
 docs/kbase/incrementalbackupinternals.rst | 23 ++++++++++++-----------
 1 file changed, 12 insertions(+), 11 deletions(-)

diff --git a/docs/kbase/incrementalbackupinternals.rst b/docs/kbase/incrementalbackupinternals.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 is also
 described as the ``active`` layer or image.

-Handling of bitmaps
--------------------
-
-Creating an external snapshot involves adding a new layer to the backing chain
-on top of the previous chain. In this step there are no new bitmaps created 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 tracking
-the changes with same granularity as before and also allows libvirt to stitch
-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 previously
+active image. Libvirt requires that all ``block-dirty-bitmaps`` which correspond
+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 default
+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 active
+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:
-- 
2.26.2

Re: [PATCH 2/6] kbase: incrementalbackupinternals: Clarify language in snapshots section
Posted by Eric Blake 5 years, 7 months ago
On 6/24/20 9:07 AM, Peter Krempa wrote:
> Emphaisze what needs to happen and also that creating a snapshot doesn't

Emphasize

> create the appropriate bitmaps. Also mention that granularity is kept.
> 
> Signed-off-by: Peter Krempa <pkrempa@redhat.com>
> ---
>   docs/kbase/incrementalbackupinternals.rst | 23 ++++++++++++-----------
>   1 file changed, 12 insertions(+), 11 deletions(-)
> 
> diff --git a/docs/kbase/incrementalbackupinternals.rst b/docs/kbase/incrementalbackupinternals.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 is also
>   described as the ``active`` layer or image.
> 
> -Handling of bitmaps
> --------------------
> -
> -Creating an external snapshot involves adding a new layer to the backing chain
> -on top of the previous chain. In this step there are no new bitmaps created 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 tracking
> -the changes with same granularity as before and also allows libvirt to stitch
> -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 previously
> +active image. Libvirt requires that all ``block-dirty-bitmaps`` which correspond
> +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 default
> +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 active

s/(see below.) bitmaps/bitmaps (see below)/

> +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:
> 

With the fixes,
Reviewed-by: Eric Blake <eblake@redhat.com>

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3226
Virtualization:  qemu.org | libvirt.org