Thursday, April 30, 2009

Hyper-V snapshots are taking up a large amount of disk space

This has been a popular topic in the forums recently.
The scenario:  a VM is on a volume, everything is happy.
As time passes, a few snapshots are taken (for various reasons) and suddenly the disk utilization is through the roof.
What is going on?
A few things might be going on, there are a bunch of variables in the equation.
Variable 1:
How much change happened after the snapshot was taken?
Differencing disks are an overlay map, therefore you could totally re-install the VM after a snapshot and thus your VHD would be limited to the same size (the size limit of the VHD).  However, on your storage volume it would now take up twice as much space.
Variable 2:
Was the VM running when you took the snapshot?
Here is a big one.  If the VM was running the VM can be restored to that previously running state.  Thus all that occupied memory space must be saved as well.   Now, not only is the disk (potentially) using more storage, but the SQL instance in the VM was set to use 2Gb of RAM, and all of that memory space must be saved as well.
Variable 3:
What is the location of the snapshot files?
Was the default %systemroot% location changed so the snapshots reside with the VM?
The actual snapshot files can be held on any locally presented storage, they don’t have to reside with the VHD.
there are more variables, but these are the big ones that have quick and hard impact that are easy to affect.
Just some forward thinking is required.

Here is my addition from a recent forum post:
.bin files are memory snapshots - these can be as large as the configured RAM of your VM.


.avhd are the differencing disks that make up a differencing disk chain, which is the way that snapshots are implemented under the hood.

the Default behavior with R2 is that all VM files (except the configuration) are held in the same directory, where the VM virtual disks are stored (the root folder of the VM). This makes VM migration much easier and fool-proof.

The hitch with using differencing disks is that a child differencing disk can be as large as its parent. Don't think dynamic disks either. A dynamic disk has a maximum size and it is that maximum size that you must be thinking of.

This being said if you create a new VM and take the default of a 127 Gb Dynamic disk. you have the potential of consuming 127 Gb of storage. If you create a snapshot you sitll have the potential of consuming 127 Gb or storage - PLUS the storage that you already consumed withthe VHD. If you create snapshot #2 you have the potential of consuming 127 Gb of storage plus the amount of storage you consumed with the VHD and the AVHD from snapshot one. And this continues.

If you take snapshots of running VMs, then you also have the storage required to hold the memory of the running VM. Therefore, yet more storage.

3 comments:

bandara said...

How we can remove it

bandara said...

How we can get redoff this issue

BrianEh said...

You cannot "get rid of" this behavior. It is by design. It is a side effect of the design.

It is the underlying use of differencing disks that causes one aspect of the issue. It is saving the RAM of the VM that causes another aspect (if you took the snapshot while the VM was running).

The way to prevent the issue to not hold on to snapshots. The design of snapshots for use in production is to take a snapshots, try your change, approve (delete the snapshot) or don't approve your change (revert), power off the vm to allow the merge, move forward.

If I did not answer your question, I guess that I am not clear about your question.