VMware Snapshot in a nutshell


                 In VMware, snapshot refers to the copy of the virtual machine disk file (VMDK) at a certain point in time. In addition to the VMDK file, it copies the content in vRAM and VM settings at that point of time. 


Snapshot creation

When you create a snapshot, the disk which was writable becomes read-only and a new delta file will be created.This delta file will contain all changes (delta) to the original disk files.When you create multiple snapshots, new delta files are created and the previous delta files become read-only. With multiple snapshots each delta file can potentially grow as large as the original disk file.


Snapshot deletion


The process for deleting multiple snapshots has changed across vSphere versions. 


vSphere 4.0 versions and VMware Infrastructure 3 (VI3) :


If a VM has 3 active snapshots and you deleted them, the following process occurs: 

  • Snapshot 3 is copied to Snapshot 2, which is then copied to Snapshot 1.
  • Snapshot 1 is copied to the original disk file, and the helper snapshot (which writes any changes occur during the snapshot) is copied to the original disk file.
  • This process requires extra disk space because each snapshot grows as the previous snapshot is added to it. If there isn't sufficient free disk space on the data store, the snapshots cannot be committed.
vSphere 4.0 versions and later :

Each snapshot is merged directly into the original disk, instead of merging with the previous snapshot. Because each snapshot is directly merged into the original one at a time, no extra disk space is needed, except for the helper file.


Snapshots that have been active for a very long time (thereby becoming extremely large) can take a very long time to commit when deleted. The amount of time the snapshot takes to commit varies depending on the VM's activity level; it will commit faster if it is powered off.



Snapshot files

*--delta.vmdk file: This is the differential file created when you take a snapshot of a VM. It is also known as the redo-log file. A delta file will be created for each snapshot that you create for a VM. An extra delta helper file will also be created to hold any disk changes when a snapshot is being deleted or reverted. It contains any changes that are made to the VM's disk while the snapshot is deleted. The size of the helper delta file varies and it's based on how long the snapshot takes to delete.


*.vmsd file: This file is used to store metadata and information about snapshots. This file does not cleanup completely after the snapshots are taken. Once you delete a snapshot, it will still increment the snapshot's last unique identifier for the next snapshot.


*.vmsn file: This is the snapshot state file, which stores the exact running state of a virtual machine at the time you take that snapshot. This file will either be small or large depending on if you select to preserve the VM's memory as part of the snapshot. If you do choose to preserve the VM's memory, then this file will be a few megabytes larger than the maximum RAM memory allocated to the VM.

This file is similar to the VMware suspended state (.vmss) file. A .vmsn file will be created for each snapshot taken on the VM; these files are automatically deleted when the snapshot is removed.

Snapshot and its performance

  1. When you first create a snapshot, your VM activity will pause briefly; if you ping a VM while creating a snapshot you will notice a few timeouts.
  2. If a snapshot is active, the performance of the VM will be degraded because the host writes to delta files differently and less efficiently than it does to standard VMDK files.
  3. The delta file grows by each 16 MB increment (discussed in part one of this series), it will cause another metadata lock. This can affect your VMs and hosts.
  4. Deleting/committing a snapshot creates a metadata lock.
  5. Snapshot you are deleting can create greatly reduced performance on its VM while the delta files are being committed; this will be more noticeable if the VM is very busy.
Things to remember
  • It is not possible to expand a VM's virtual disk while a snapshot is running, if you try the vmkfstools command, you receive an error: Failed to extend the disk. Failed to lock the file. With the vSphere Client, if you edit a VM's settings when a snapshot is running, and then select one of its virtual disks, the option to resize the disk is grayed out. But once the snapshot is deleted, you can resize the virtual disk.
  • If you have a VM with more than one disk and you wish to exclude a disk from being included in a snapshot, you must edit the VM's settings by changing the disk mode to Independent (make sure you select Persistent). The independent setting provides you the means to control how each disk functions independently, there is no difference to the disk file or structure. Once a disk is Independent it will not be included in any snapshots. You will not be able to include memory snapshots on a VM that has independent disks.
  • The size of a snapshot file can never exceed the size of the original disk file. There will be an overhead disk space that contains information used to manage the snapshots. This varies according to the VMFS block size. For eg: 1 MB block sized VMFS volume will have a maximum overhead of 2 GB. 
  • Snapshot files will initially be small (16 MB), but will grow as writes are made to the VM's disk files. Snapshots grow in 16 MB increments to help reduce SCSI reservation conflicts. When requests are made to change a block on the original disk, it is instead changed in the delta file.


Comments

Popular posts from this blog

VMware and Windows Interview Questions: Part 2

VMware and Windows Interview Questions: Part 3

VMware vMotion error at 14%