Understanding snapshots and differencing disks

[ChipMcK]

I have been reading these forums for a couple of years now. I have gleaned the following about SnapShots.

When a virtual disk is first created for a new virtual machine, it is considered
as the base disk for the guest - data for the guest is read from and written to that disk image.

First SnapShot creates a differencing disk (diffDisk#1) for read/write access while the base disk becomes read-only - as the guest modifies its data, the data is written to the differencing disk and the base disk is untouched.

Second SnapShot creates another, new, differencing disk (diffDisk#2) for read/write access while the first differencing disk (diffDisk#1) becomes read-only along with the base disk.

Subsequent SnapShots create additional differencing disks, with the preceding differencing disk joining the hierarchy (pecking order/chain) of read-only disks.

Is the above accurate?

--------------------------
Edted to fix typos

[mpack]

Somehow missed this previously. Yes, it is accurate. The only thing you miss out is, "ok, now what happens if I delete/corrupt the base VDI or the control xml file". Oh, and a chain is of course the simplest scenario, but branching snapshots have been supported for a while too - that's when a frozen parent has two or more directly linked difference chains attached to it.

And just to emphasise: when we talk about new data being written to the difference files, we are talking about changed disk sectors - i.e. fragments of files, not whole files. I emphasise that because lots of people assume that it works like having a new filing cabinet and locking the old one - complete files would go into the new cabinet, but that aint how it works. In fact the new filing cabinet just contains fragments - words, maybe a complete sentence or two - but useless without the first cabinet.

[ChipMcK]

Ah, the differencing disk records changes sector-by-sector to the whole disk image, not changes to any file in the disk.
VirtualBox does not know what file system is employed on the disk image and therefore can not access any individual file of/on the disk image; only the guest OS is aware of that information.

[mpack]

Yes, VirtualBox knows nothing about guest filesystems. In essence it is a hardware simulator. In the case of disk hardware it can sense when something writes to the disk (and at what sector addresses), but it knows nothing about the content of what is being written.

[joeller]

The Virtual Box manual states:

You can also delete a snapshot, which will not affect the state of the virtual machine, but
only release the files on disk that VirtualBox used to store the snapshot data, thus freeing
disk space. To delete a snapshot, right-click on it in the snapshots tree and select “Delete”.
As of VirtualBox 3.2, snapshots can be deleted even while a machine is running.

If you have two snapshots in the tree is it necessary to delete the most recent first or vice versa?

[mpack]

You should think of a snapshot chain not as a series of disk images, but as a single disk image with a time axis. On that time axis are some markers. The idea is that you can reset the VM current state to how it was at any of the marked times. And of course - you can remove any of the markers you like, in any order - after which you will lose the ability to revert to that time.

Things get more complicated because of course VirtualBox allows branches too, not just simple chains. Obviously one cannot delete a marker that two different chains depart from.

Also note that deleting a marker is not at all the same operation as reverting to the time represented by the marker.

[joeller]

Also note that deleting a marker is not at all the same operation as reverting to the time represented by the marker.

Understood. We are trying to roll up all the snapshots into the current image because they are taking up too much disk space. (87 Gigs)

As I understand it the lastest sanpshot VDI represents an incremental file from the time the latest snapshot was taken to the current time and each snapshot in the chain is an incremental file from the previous snapshot. I am hoping that deleting all the snapshots and rolling the information into the current VDI will result in less disk space usage. Right now we have a VDI file under the V Machine's folder of about 5 gigs presumably the base vdi, and two snapshot VDIs in the snapshots folder. (Interestingly enough the latest last modified date on the latest vdi in the snapshots folder is exactly the same as that on the vdi in the VM folder. But if the base vdi is frozen then why does its latest modified date read the same as the most recent the most recent snapshot?)

Before we do this we are backing everything up just to make sure we can go back to what we need.

[mpack]

Since VBox v4.1.0 or later, one quick way to get rid of all snapshots (and other forms of differencing disk) is simply to clone the VM, selecting a full clone, current state only. After testing that the clone works, you can delete the old VM. One caveat is that this involves creating a new VM - with a new VM UUID - plus new virtual disks, all with new disk UUIDs. In some guest OS's these changes can cause problems (*) - but usually doesn't, and the problems are fixable. In any case you still have the original VM to return to if the clone fails.

Potential UUID change problems :-

• Windows guests see the UUID changes as hardware changes, and may ask to be reactivated. This should not present a problem if the last activation was 120+ days ago, just go ahead and do it.
• Linux guests may fail with a grub boot error. In this case reconfigure the grub boot script so that either the new boot disk UUID is used, or better yet is let the boot disk be referenced by device name rather than UUID as this means that you won't keep getting the problem on future clones.

[joeller]

I was going to ask about CloneVDI but decided that this was not the forum. But since you bring it up....

This was part of the CloneVDI release notes.

Q. Can it clone VDIs with snapshots?
A. Yes, CloneVDI v2.00 now has the ability to clone a snapshot VDI (the .VDI files with the strange
names that live in your \Machine\Snapshots folder). It will follow the chain of dependencies back
to the base VDI and then create a clone which includes all the data from the point in time
represented by the snapshot. However this feature only works with VirtualBox native (VDI)
snapshots. Snapshots in other formats (such as VHD and VMDK) are not yet supported.

Which seems to say that all sanpshots are rolled into a new base VDI.
It also states...

2. Options
Select "Generate new UUID" if you intend to use both original and clone on the same host PC.
Selecting "Keep old UUID" is a possibility if you plan to delete the original file or use the clone
on a different PC.

Which would let me delete the old machine. But it goes on to say..

Note that if you use the "Keep" option then only the creation UUID is inherited
by the clone. The "modification" UUID is given a new value. If you were unwise enough to clone and
replace the base VDI for a snapshot chain then this should ensure that the error is not catastrophic
(VBox should complain - correctly - that the base VDI has been modified, at which time you should
restore the original VDI).

Which seems to tell me that it is necessary to roll up the snapshots before doing the clone if you want to keep the same UUID.

Do you concur?

[mpack]

In fact I did not mention CloneVDI, nor am I willing to discuss it here.

[joeller]

OK then.

I will go to the "CloneVDI tool - Discussion & Support" topic as I originally intended.