[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [libvirt] [PATCH] docs: Add detailed notes snapshots, blockcommit, blockpull



Eric,

I wonder if you still have some time to take a look at this.

Thanks.

On 10/23/2012 03:28 PM, Kashyap Chamarthy wrote:
> More elaborate notes on snapshots, blockpull, blockcommit.  Much of this
> is derived from various dicussions with Eric Blake, Jeff Cody, Kevin Wolf
> (thanks a lot!) & several others on IRC and mailing lists and a lot of adhoc
> testing. I didn't wanted this to get lost.
> 
> I also plan to add notes for 'blockcopy' once I complete testing with upstream
> libvirt/qemu git.
> 
> NOTE: This document is formatted using reStructuredText. And can be trivially
> converted to HTML using:
> # rst2html snapshots-blockcommit-blockpull.rst > snapshots-blockcommit-blockpull.html
> 
> ('rst2html' is part of python-docutils package.)
> 
> I didn't send an html PATCH directly, as I thought, this'd be more readable.
> 
> Any comments, criticisms more than welcome.
> 
> 
> ---
>  docs/snapshots-blockcommit-blockpull.rst |  646 ++++++++++++++++++++++++++++++
>  1 files changed, 646 insertions(+), 0 deletions(-)
>  create mode 100644 docs/snapshots-blockcommit-blockpull.rst
> 
> diff --git a/docs/snapshots-blockcommit-blockpull.rst b/docs/snapshots-blockcommit-blockpull.rst
> new file mode 100644
> index 0000000000000000000000000000000000000000..99c30223a004ee5291e2914b788ac7fe04eee3c8
> --- /dev/null
> +++ b/docs/snapshots-blockcommit-blockpull.rst
> @@ -0,0 +1,646 @@
> +.. ----------------------------------------------------------------------
> +   Note: All these tests were performed with latest qemu-git,libvirt-git (as of
> +   20-Oct-2012 on a Fedora-18 alpha machine
> +.. ---------------------------------------------------------------------- 
> +
> +
> +Introduction 
> +============
> +
> +A virtual machine snapshot is a view of a virtual machine(its OS & all its
> +applications) at a given point in time. So that, one can revert to a known sane
> +state, or take backups while the guest is running live. So, before we dive into
> +snapshots, let's have an understanding of backing files and overlays.
> +
> +        
> +
> +QCOW2 backing files & overlays
> +------------------------------
> +
> +In essence, QCOW2(Qemu Copy-On-Write) gives you an ability to create a base-image,
> +and create several 'disposable' copy-on-write overlay disk images on top of the
> +base image(also called backing file). Backing files and overlays are
> +extremely useful to rapidly instantiate thin-privisoned virtual machines(more on
> +it below). Especially quite useful in development & test environments, so that
> +one could quickly revert to a known state & discard the overlay.
> +
> +**Figure-1**
> +
> +::
> +
> +  .--------------.    .-------------.    .-------------.    .-------------.
> +  |              |    |             |    |             |    |             |
> +  | RootBase     |<---| Overlay-1   |<---| Overlay-1A  <--- | Overlay-1B  |
> +  | (raw/qcow2)  |    | (qcow2)     |    | (qcow2)     |    | (qcow2)     |
> +  '--------------'    '-------------'    '-------------'    '-------------'
> +
> +The above figure illustrates - RootBase is the backing file for Overlay-1, which
> +in turn is backing file for Overlay-2, which in turn is backing file for
> +Overlay-3.
> +
> +**Figure-2**
> +::
> +
> + .-----------.   .-----------.   .------------.  .------------.  .------------.
> + |           |   |           |   |            |  |            |  |            |
> + | RootBase  |<--- Overlay-1 |<--- Overlay-1A <--- Overlay-1B <--- Overlay-1C |
> + |           |   |           |   |            |  |            |  | (Active)   |
> + '-----------'   '-----------'   '------------'  '------------'  '------------'
> +    ^    ^
> +    |    |
> +    |    |       .-----------.    .------------.
> +    |    |       |           |    |            |
> +    |    '-------| Overlay-2 |<---| Overlay-2A |
> +    |            |           |    | (Active)   |
> +    |            '-----------'    '------------'
> +    |
> +    |
> +    |            .-----------.    .------------.
> +    |            |           |    |            |
> +    '------------| Overlay-3 |<---| Overlay-3A |
> +                 |           |    | (Active)   |
> +                 '-----------'    '------------'
> +                
> +The above figure is just another representation which indicates, we can use a
> +'single' backing file, and create several overlays -- which can be used further,
> +to create overlays on top of them.
> +
> +
> +**NOTE**: Backing files are always opened **read-only**. In other words, once 
> +          an overlay is created, its backing file should not be modified(as the
> +          overlay depends on a particular state of the backing file). Refer
> +          below ('blockcommit' section) for relevant info on this.
> +
> +
> +**Example** :
> +
> +::
> +
> +    [FedoraBase.img] ----- <- [Fedora-guest-1.qcow2] <- [Fed-w-updates.qcow2] <- [Fedora-guest-with-updates-1A]
> +                     \
> +                      \--- <- [Fedora-guest-2.qcow2] <- [Fed-w-updates.qcow2] <- [Fedora-guest-with-updates-2A]
> +
> +(Arrow to be read as Fed-w-updates.qcow2 has Fedora-guest-1.qcow2 as its backing file.)
> +
> +In the above example, say, *FedoraBase.img* has a freshly installed Fedora-17 OS on it,
> +and let's establish it as our backing file. Now, FedoraBase can be used as a
> +read-only 'template' to quickly instantiate two(or more) thinly provisioned
> +Fedora-17 guests(say Fedora-guest-1.qcow2, Fedora-guest-2.qcow2) by creating
> +QCOW2 overlay files pointing to our backing file. Also, the example & *Figure-2*
> +above illustrate that a single root-base image(FedoraBase.img) can be used
> +to create multiple overlays -- which can subsequently have their own overlays.
> +
> +
> +    To create two thinly-provisioned Fedora clones(or overlays) using a single
> +    backing file, we can invoke qemu-img as below: ::
> +
> +
> +        # qemu-img create -b /export/vmimages/RootBase.img -f qcow2 \
> +          /export/vmimages/Fedora-guest-1.qcow2
> +
> +        # qemu-img create -b /export/vmimages/RootBase.img -f qcow2 \
> +          /export/vmimages/Fedora-guest-2.qcow2
> +    
> +    Now, both the above images *Fedora-guest-1* & *Fedora-guest-2* are ready to
> +    boot. Continuting with our example, say, now you want to instantiate a
> +    Fedora-17 guest, but this time, with full Fedora updates. This can be
> +    accomplished by creating another overlay(Fedora-guest-with-updates-1A) - but
> +    this overly would point to 'Fed-w-updates.qcow2' as its backing file (which
> +    has the full Fedora updates) ::
> +
> +         # qemu-img create -b /export/vmimages/Fed-w-updates.qcow2 -f qcow2 \
> +           /export/vmimages/Fedora-guest-with-updates-1A.qcow2
> +
> +
> +    Information about a disk image, like virtual size, disk size, backing file(if it
> +    exists) can be obtained by using 'qemu-img' as below:
> +    ::
> +
> +        # qemu-img info /export/vmimages/Fedora-guest-with-updates-1A.qcow2
> +
> +    NOTE: With latest qemu, an entire backing chain can be recursively
> +    enumerated by doing:
> +    ::
> +
> +        # qemu-img info --backing-chain /export/vmimages/Fedora-guest-with-updates-1A.qcow2
> +       
> +
> +
> +Snapshot Terminology:
> +---------------------
> +
> +    - **Internal Snapshots** -- A single qcow2 image file holds both the saved state
> +        & the delta since that saved point. This can be further classified as :-
> +
> +        (1) **Internal disk snapshot**: The state of the virtual disk at a given
> +            point in time. Both the snapshot & delta since the snapshot are
> +            stored in the same qcow2 file. Can be taken when the guest is 'live'
> +            or 'offline'.
> +
> +                - Libvirt uses QEMU's 'qemu-img' command when the guest is 'offline'.
> +                - Libvirt uses QEMU's 'savevm' command when the guest is 'live'.
> +
> +        (2) **Internal system checkpoint**: RAM state, device state & the
> +            disk-state of a running guest, are all stored in the same originial
> +            qcow2 file. Can be taken when the guest is running 'live'.
> +
> +                - Libvirt uses QEMU's 'savevm' command when the guest is 'live'
> +
> +
> +    - **External Snapshots** -- Here, when a snapshot is taken, the saved state will
> +      be stored in one file(from that point, it becomes a read-only backing
> +      file) & a new file(overlay) will track the deltas from that saved state.
> +      This can be further classified as :-
> +
> +        (1) **External disk snapshot**: The snapshot of the disk is saved in one
> +            file, and the delta since the snapshot is tracked in a new qcow2
> +            file. Can be taken when the guest is 'live' or 'offline'.
> +
> +                - Libvirt uses QEMU's 'transaction' cmd  under the hood, when the
> +                  guest is 'live'.
> +
> +                - Libvirt uses QEMU's 'qemu-img' cmd under the hood  when the
> +                  guest is 'offline'(this implementation is in progress, as of
> +                  writing this).
> +
> +        (2) **External system checkpoint**: Here, the guest's disk-state will be
> +            saved in one file, its RAM & device-state will be saved in another
> +            new file (This implementation is in progress upstream libvirt, as of
> +            writing this).
> +
> +
> +
> +    - **VM State**: Saves the RAM & device state of a running guest(not 'disk-state') to
> +      a file, so that it can be restored later. This simliar to doing hibernate
> +      of the system. (NOTE: The disk-state should be unmodified at the time of
> +      restoration.) 
> +
> +            - Libvirt uses QEMU's 'migrate' (to file) cmd under the hood.      
> +
> +
> +
> +Creating snapshots
> +==================
> +    - Whenever an 'external' snapshot is issued, a /new/ overlay image is
> +      created to facilitate guest writes, and the previous image becomes a
> +      snapshot.
> +
> +    - **Create a disk-only internal snapshot**
> +        
> +        (1) If I have a guest named 'f17vm1', to create an offline or online
> +            'internal' snapshot called 'snap1' with description 'snap1-desc' ::
> +
> +            # virsh snapshot-create-as f17vm1  snap1 snap1-desc 
> +       
> +        (2) List the snapshot ; and query using *qemu-img* tool to view
> +            the image info & its internal snapshot details ::
> +
> +            # virsh snapshot-list f17vm1
> +            # qemu-img info /home/kashyap/vmimages/f17vm1.qcow2
> +            
> +
> +
> +    - **Create a disk-only external snapshot** :
> +
> +        (1) List the block device associated with the guest. ::
> +
> +                # virsh domblklist f17-base
> +                Target     Source
> +                ---------------------------------------------
> +                vda        /export/vmimages/f17-base.qcow2
> +
> +                #
> +
> +        (2) Create external disk-only snapshot (while the guest is *running*). ::
> +
> +                # virsh snapshot-create-as --domain f17-base snap1 snap1-desc \
> +                --disk-only --diskspec vda,snapshot=external,file=/export/vmimages/sn1-of-f17-base.qcow2 \
> +                --atomic
> +                Domain snapshot snap1 created
> +                #
> +              
> +                    * Once the above command is issued, the original disk-image
> +                    of f17-base will become the backing_file & a new overlay
> +                    image is created to track the new changes. Here on, libvirt
> +                    will use this overlay for further write operations(while
> +                    using the original image as a read-only backing_file).
> +
> +        (3) Now, list the block device associated(use cmd from step-1, above)
> +            with the guest,again, to ensure it reflects the new overlay image as
> +            the current block device in use. ::
> +
> +                # virsh domblklist f17-base
> +                Target     Source
> +                ----------------------------------------------------
> +                vda        /export/vmimages/sn1-of-f17-base.qcow2
> +
> +                #
> +
> +
> +        
> +
> +Reverting to snapshots
> +======================
> +As of writing this, reverting to 'Internal Snapshots'(system checkpoint or
> +disk-only) is possible.
> +
> +    To revert to a snapshot named 'snap1' of domain f17vm1 ::
> +
> +    # virsh snapshot-revert --domain f17vm1 snap1
> +
> +Reverting to 'external disk snapshots' using *snapshot-revert* is a little more
> +tricky, as it involves slightly complicated process of dealing with additional
> +snapshot files - whether to merge 'base' images into 'top' or to merge other way
> +round ('top' into 'base').
> +
> +That said, there are a couple of ways to deal with external snapshot files by
> +merging them to reduce the external snapshot disk image chain by performing
> +either a **blockpull** or **blockcommit** (more on this below). 
> +
> +Further improvements on this front is in work upstream libvirt as of writing
> +this.
> +
> +
> +
> +Merging snapshot files
> +======================
> +External snapshots are incredibly useful. But, with plenty of external snapshot
> +files, there comes a problem of maintaining and tracking all these inidivdual
> +files. At a later point in time, we might want to 'merge' some of these snapshot
> +files (either backing_files into overlays or vice-versa) to reduce the length of
> +the image chain. To accomplish that, there are two mechanisms:
> +
> +    + blockcommit: merges data from  **top** into **base** (in other
> +      words, merge overlays into backing files).
> +
> +
> +    + blockpull: Populates a disk image with data from its backing file. Or
> +      merges data from **base** into **top** (in other words, merge backing files
> +      into overlays).
> +
> +
> +blockcommit
> +-----------
> +
> +Block Commit allows you to merge from a 'top' image(within a disk backing file
> +chain) into a lower-level 'base' image. To rephrase, it allows you to
> +merge overlays into backing files. Once the **blockcommit** operation is finished,
> +any portion that depends on the 'top' image, will now be pointing to the 'base'.
> +
> +This is useful in flattening(or collapsing or reducing) backing file chain
> +length after taking several external snapshots.
> +
> +
> +Let's understand with an illustration below:
> +
> +We have a base image called 'RootBase', which has a disk image chain with 4
> +external snapshots. With 'Active' as the current active-layer, where 'live' guest
> +writes happen. There are a few possibilities of resulting image chains that we
> +can end up with, using 'blockcommit' : 
> +
> +    (1) Data from Snap-1, Snap-2 and Snap-3 can be merged into 'RootBase'
> +        (resulting in RootBase becoming the backing_file of 'Active', and thus
> +        invalidating Snap-1, Snap-2, & Snap-3).
> +
> +    (2) Data from Snap-1 and Snap-2 can be merged into RootBase(resulting in
> +        Rootbase becoming the backing_file of Snap-3, and thus invalidating
> +        Snap-1 & Snap-2).
> +
> +    (3) Data from Snap-1 can be merged into RootBase(resulting in RootBase
> +        becoming the backing_file of Snap-2, and thus invalidating Snap-1).
> +    
> +    (4) Data from Snap-2 can be merged into Snap-1(resulting in Snap-1 becoming
> +        the backing_file of Snap-3, and thus invalidating Snap-2).
> +
> +    (5) Data from Snap-3 can be merged into Snap-2(resulting in Snap-2 becoming
> +        the backing_file for 'Active', and thus invalidating Snap-3).
> +
> +    (6) Data from Snap-2 and Snap-3 can be merged into Snap-1(resulting in
> +        Snap-1 becoming the backing_file of 'Active', and thus invalidating
> +        Snap-2 & Snap-3).
> +
> +    NOTE: Eventually(not supported in qemu as of writing this), we can also
> +          merge down the 'Active' layer(the top-most overlay) into its
> +          backing_files.  Once it is supported, the 'top' argument can become
> +          optional, and default to active layer.
> +
> +
> +(The below figure illustrates case (6) from the above)
> +
> +**Figure-3**
> +::
> +
> + .------------.  .------------.  .------------.  .------------.  .------------.
> + |            |  |            |  |            |  |            |  |            |
> + | RootBase   <---  Snap-1    <---  Snap-2    <---  Snap-3    <---  Snap-4    |
> + |            |  |            |  |            |  |            |  | (Active)   |
> + '------------'  '------------'  '------------'  '------------'  '------------'
> +                                  /                  |
> +                                 /                   |
> +                                /  commit data       |
> +                               /                     |
> +                              /                      |
> +                             /                       |
> +                            v           commit data  |
> + .------------.  .------------. <--------------------'           .------------.
> + |            |  |            |                                  |            |
> + | RootBase   <---  Snap-1    |<---------------------------------|  Snap-4    |
> + |            |  |            |       Backing File               | (Active)   |
> + '------------'  '------------'                                  '------------'
> +
> +For instance, if we have the below scenario:
> +    
> +    Actual: [base] <- sn1 <- sn2 <- sn3 <- sn4(this is active)
> +
> +    Desired:  [base] <- sn1 <- sn4  (thus invalidating sn2,sn3) 
> +    
> +      Any of the below two methods is valid (as of 17-Oct-2012 qemu-git). With
> +      method-a, operation will be faster & correct if we don't care about
> +      sn2(because, it'll be invalidated). Note that, method-b is slower, but sn2
> +      will remain valid. (Also note that, the guest is 'live' in all these cases).
> +    
> +        **(method-a)**:
> +            ::
> +
> +            # virsh blockcommit --domain f17 vda --base /export/vmimages/sn1.qcow2 --top /export/vmimages/sn3.qcow2 --wait --verbose
> +            
> +        [OR]
> +    
> +        **(method-b)**:
> +            ::
> +
> +             # virsh blockcommit --domain f17 vda  --base /export/vmimages/sn2.qcow2 --top /export/vmimages/sn3.qcow2 --wait --verbose
> +             # virsh blockcommit --domain f17 vda  --base /export/vmimages/sn1.qcow2 --top /export/vmimages/sn2.qcow2 --wait --verbose
> +    
> +       NOTE: If we had to do manually with *qemu-img* cmd, we can only do method-b at the moment.
> +
> +
> +**Figure-4**
> +::
> +
> + .------------.  .------------.  .------------.  .------------.  .------------.
> + |            |  |            |  |            |  |            |  |            |
> + | RootBase   <---  Snap-1    <---  Snap-2    <---  Snap-3    <---  Snap-4    |
> + |            |  |            |  |            |  |            |  | (Active)   |
> + '------------'  '------------'  '------------'  '------------'  '------------'
> +                   /                  |             |
> +                  /                   |             |
> +                 /                    |             |
> +    commit data /         commit data |             |
> +               /                      |             |
> +              /                       | commit data |
> +             v                        |             |
> + .------------.<----------------------|-------------'            .------------.
> + |            |<----------------------'                          |            |
> + | RootBase   |                                                  |  Snap-4    |
> + |            |<-------------------------------------------------| (Active)   |
> + '------------'                  Backing File                    '------------'
> +
> +
> +The above figure is another representation of reducing the disk image chain
> +using blockcommit. Data from Snap-1, Snap-2, Snap-3 are merged(/committed)
> +into RootBase, & now the current 'Active' image now pointing to 'RootBase' as its
> +backing file(instead of Snap-3, which was the case *before* blockcommit). Note
> +that, now intermediate images Snap-1, Snap-1, Snap-3 will be invalidated(as they were
> +dependent on a particular state of RootBase).
> +
> +blockpull
> +---------
> +Block Pull(also called 'Block Stream' in QEMU's paralance)  allows you to merge
> +into 'base' from a 'top' image(within a disk backing file chain). To rephrase it
> +allows  merging backing files into an overlay(active). This works in the
> +opposite side of 'blockcommit' to flatten the snapshot chain. At the moment,
> +**blockpull** can pull only into the active layer(the top-most image). It's
> +worth noting here that, intermediate images are not invalidated once a blockpull
> +operation is complete (while blockcommit, invalidates them).
> +
> +
> +Consider the below illustration:
> +
> +**Figure-5**
> +::
> +
> + .------------.  .------------.  .------------.  .------------.  .------------.
> + |            |  |            |  |            |  |            |  |            |
> + | RootBase   <---  Snap-1    <---  Snap-2    <---  Snap-3    <---  Snap-4    |
> + |            |  |            |  |            |  |            |  | (Active)   |
> + '------------'  '------------'  '------------'  '------------'  '------------'
> +                          |                 |              \
> +                          |                 |               \
> +                          |                 |                \
> +                          |                 |                 \ stream data
> +                          |                 | stream data      \
> +                          | stream data     |                   \
> +                          |                 |                    v
> +      .------------.      |                 '--------------->  .------------.
> +      |            |      '--------------------------------->  |            |
> +      | RootBase   |                                           |  Snap-4    |
> +      |            | <---------------------------------------- | (Active)   |
> +      '------------'                 Backing File              '------------'
> +
> +
> +
> +The above figure illustrates that, using block-copy we can pull data from
> +Snap-1, Snap-2 and Snap-3 into the 'Active' layer, resulting in 'RootBase'
> +becoming the backing file for the 'Active' image (instead of 'Snap-3', which was
> +the case before doing the blockpull operation).
> +
> +The command flow would be:
> +    (1) Assuming a external disk-only snapshot was created as mentioned in
> +        *Creating Snapshots* section:
> +
> +    (2) A blockpull operation can be issued this way, to achieve the desired
> +        state of *Figure-5*-- [RootBase] <- [Active]. ::
> +
> +             # virsh blockpull --domain RootBase --path var/lib/libvirt/images/active.qcow2 --base /var/lib/libvirt/images/RootBase.qcow2  --wait --verbose
> +
> +
> +    As a follow up, we can do the below to clean-up the snapshot *tracking*
> +    metadata by libvirt (note: the below does not 'remove' the files, it
> +    just cleans up the snapshot tracking metadata). ::
> + 
> +            # virsh snapshot-delete --domain RootBase Snap-3 --metadata
> +            # virsh snapshot-delete --domain RootBase Snap-2 --metadata
> +            # virsh snapshot-delete --domain RootBase Snap-1 --metadata
> +
> +
> +
> +
> +**Figure-6**
> +::
> +
> + .------------.  .------------.  .------------.  .------------.  .------------.
> + |            |  |            |  |            |  |            |  |            |
> + | RootBase   <---  Snap-1    <---  Snap-2    <---  Snap-3    <---  Snap-4    |
> + |            |  |            |  |            |  |            |  | (Active)   |
> + '------------'  '------------'  '------------'  '------------'  '------------'
> +       |                  |              |                  \
> +       |                  |              |                   \
> +       |                  |              |                    \  stream data
> +       |                  |              | stream data         \
> +       |                  |              |                      \
> +       |                  | stream data  |                       \
> +       |  stream data     |              '------------------>     v
> +       |                  |                                    .--------------.
> +       |                  '--------------------------------->  |              |
> +       |                                                       |  Snap-4      |
> +       '---------------------------------------------------->  | (Active)     |
> +                                                               '--------------'
> +                                                                 'Standalone'
> +                                                                 (w/o backing
> +                                                                 file)  
> +
> +The above  figure illustrates, once blockpull operation is complete, by
> +pulling/streaming data from RootBase, Snap-1, Snap-2, Snap-3 into 'Active', all
> +the backing files can be discarded and 'Active' now will be a standalone image
> +without any backing files.
> +
> +Command flow would be:
> +    (0) Assuming 4 external disk-only (live) snapshots were created as
> +        mentioned in *Creating Snapshots* section,
> +
> +    (1) Let's check the snapshot overlay images size *before* blockpull operation (note the image of 'Active'):
> +        :: 
> +
> +            # ls -lash /var/lib/libvirt/images/RootBase.img 
> +            608M -rw-r--r--. 1 qemu qemu 1.0G Oct 11 17:54 /var/lib/libvirt/images/RootBase.img
> +
> +            # ls -lash /var/lib/libvirt/images/*Snap*
> +            840K -rw-------. 1 qemu qemu 896K Oct 11 17:56 /var/lib/libvirt/images/Snap-1.qcow2
> +            392K -rw-------. 1 qemu qemu 448K Oct 11 17:56 /var/lib/libvirt/images/Snap-2.qcow2
> +            456K -rw-------. 1 qemu qemu 512K Oct 11 17:56 /var/lib/libvirt/images/Snap-3.qcow2
> +            2.9M -rw-------. 1 qemu qemu 3.0M Oct 11 18:10 /var/lib/libvirt/images/Active.qcow2
> +
> +    (2) Also, check the disk image information of 'Active'. It can noticed that
> +        'Active' has Snap-3 as its backing file. ::
> +
> +            # qemu-img info /var/lib/libvirt/images/Active.qcow2
> +            image: /var/lib/libvirt/images/Active.qcow2
> +            file format: qcow2
> +            virtual size: 1.0G (1073741824 bytes)
> +            disk size: 2.9M
> +            cluster_size: 65536
> +            backing file: /var/lib/libvirt/images/Snap-3.qcow2
> +
> +    (3) Do the **blockpull** operation. ::
> +    
> +            # virsh blockpull --domain ptest2-base --path /var/lib/libvirt/images/Active.qcow2 --wait --verbose
> +            Block Pull: [100 %]
> +            Pull complete
> +
> +    (4) Let's again check the snapshot overlay images size *after*
> +        blockpull operation. It can be noticed, 'Active' is now considerably larger. ::
> +            
> +            # ls -lash /var/lib/libvirt/images/*Snap*
> +             840K -rw-------. 1 qemu qemu 896K Oct 11 17:56 /var/lib/libvirt/images/Snap-1.qcow2
> +             392K -rw-------. 1 qemu qemu 448K Oct 11 17:56 /var/lib/libvirt/images/Snap-2.qcow2
> +             456K -rw-------. 1 qemu qemu 512K Oct 11 17:56 /var/lib/libvirt/images/Snap-3.qcow2
> +            1011M -rw-------. 1 qemu qemu 3.0M Oct 11 18:29 /var/lib/libvirt/images/Active.qcow2
> +
> +
> +    (5) Also, check the disk image information of 'Active'. It can now be
> +        noticed that 'Active' is a standalone image without any backing file -
> +        which is the desired state of *Figure-6*.::
> +
> +            # qemu-img info /var/lib/libvirt/images/Active.qcow2
> +            image: /var/lib/libvirt/images/Active.qcow2
> +            file format: qcow2
> +            virtual size: 1.0G (1073741824 bytes)
> +            disk size: 1.0G
> +            cluster_size: 65536
> +
> +    (6) We can now clean-up the snapshot tracking metadata by libvirt to
> +        reflect the new reality ::
> +
> +            # virsh snapshot-delete --domain RootBase Snap-3 --metadata
> +
> +    (7) Optionally, one can check, the guest disk contents by invoking
> +        *guestfish* tool(part of *libguestfs*)  **READ-ONLY** (*--ro* option
> +        below does it) as below ::
> +
> +            # guestfish --ro -i -a /var/lib/libvirt/images/Active.qcow2
> +
> +        
> +Deleting snapshots (and 'offline commit')
> +=========================================
> +
> +Deleting (live/offline) *Internal Snapshots* (where the originial & all the named snapshots
> +are stored in a single QCOW2 file),  is quite straight forward. ::
> +
> +    # virsh snapshot-delete --domain f17vm --snapshotname snap6
> +
> +    [OR]
> +
> +    # virsh snapshot-delete f17vm snap6
> +
> +Deleting External snapshots (offline), Libvirt has not acquired the capability.
> +But, it can be done via *qemu-img* manipulation.
> +
> +Say, we have this image chain(the guest is *offline* here): **base <- sn1 <- sn2 <- sn3**
> +(arrow to be read as 'sn3 has sn2 as its backing file').
> +
> +
> +And, we want to delete the second snapshot(sn2). It's possible to do it in two
> +ways:
> +
> +
> +    - **Method (1)**: **base <- sn1 <- sn3**   (by copying sn2 into sn1)    
> +    - **Method (2)**: **base <- sn1 <- sn3**   (by copying sn2 into sn3)
> +
> +Method (1)
> +----------
> +To end up with this image chain : **base <- sn1 <- sn3**  (by copying *sn2* into *sn1*)
> +
> +**NOTE**: This is only possible *if* sn1 isn't used by more images as their backing
> +file, or they'd get corrupted!!
> +
> +    (a) We're doing an *offline commit* (similar to what  *blockcommit* can do
> +    to an *online* guest). ::
> +
> +        # qemu-img commit sn2.qcow2
> +      
> +            - This will *commit* the changes from sn2 into its backing file(which is
> +              sn1).
> +
> +    (b) Now that we've comitted changes from sn2 into sn1, let's change the
> +        backing file link in sn3 to point to sn1. ::
> +    
> +        # qemu-img rebase -u -b sn1.qcow2 sn3.qcow2
> +    
> +            - **NOTE**: This is 'Unsafe mode' -- in this mode, only the backing file
> +              name is changed w/o any checks on the file contents. The user must
> +              take care of specifying the correct new backing file, or the
> +              guest-visible. This mode is useful for renaming or moving the
> +              backing file to somewhere else.  It can be used without an
> +              accessible old backing file, i.e. you can use it to fix an image
> +              whose backing file has already been moved/renamed.
> +
> +
> +    (c) Now, we can delete the sn2 disk image(as the changes are now committed
> +        to sn1). ::
> +
> +          # rm sn2.qcow2
> +
> +
> +Method (2)
> +----------
> +To end up with this image chain : **base <- sn1 <- sn3**  (by copying *sn2* into *sn3*)
> +
> +    (a) Copy contents of sn2(the old backing file) into sn3, and change the backing file link of sn3 to sn1::
> +
> +        # qemu-img rebase -b sn1.qcow2 sn3.qcow2
> + 
> +            - Apart from changing backing file link of sn3 to sn1, the above cmd
> +              will it also /copy/ the contents from sn2 into sn3).
> +
> +            - In other words: This is 'Safe mode', which is the default --
> +              any clusters that differ between the new  backing_file(in this
> +              case, sn1) and the old backing file(in this case, sn2) of
> +              filename(in this case, sn3) are merged into filename(sn3), before
> +              actually changing the backing file.
> +
> +    (b) Now, we can delete the sn2 disk image(as the changes are now committed to
> +        sn1). ::
> +
> +        # rm sn2.qcow2
> +                
> 


-- 
/kashyap


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]