Snapshots and Coalescence


This week has been rather busy both professionally, personally, numerically, technologically and maybe event ecumenically.  And not in that order.

Much like my thoughts over the last five days, I have a base image of everything I hope to accomplish in my life.  However, my never ending hunger for knowledge and creativity (often referred to as ADHD) leaves me feeling a bit like a XenServer Guest VM: snapshot after snapshot being deleted and coalesced back into its predecessor via true, human real time.

All of this should not be taken under the context of “Woe is Xenfomaton!”, quite the contrary, for as fast as my actions may be in producing tangible works, my list of things to accomplish will most likely be the last thing I – or anyone – leave in a complete fashion.

With all of this strangeness out of the way, let’s take this vague comparisons and adjust course towards Guest VMs under XenServer: snapshots, more snapshots, and coalescence.

So, why focus on this topic? Why all the fracas?

You ask such great questions and as such I will start answering by first addressing what a snapshot is and is not.

Once a VM is up and running, many hypervisors allow administrators to capture the live state of a VM: disks, memory and the works. Think of it as a photograph of a wonderful moment in time. If someone’s memory fades, they can look at the photograph and, in conjunction with their base memories, will suddenly remember the entirety of events surrounding that photograph.

Thus, a snapshot is a difference (or delta) of time from a VMs life.

The snapshot, or multiple snapshots, depend on each other. More importantly, they depend on the original VM’s disks (known as base disks) to be present. Without a good base disk or if excessive snapshots have been taken, these disks containing mathematical differences now become “photographs from some other family.”

As such, a snapshot is NOT a backup of a VM.

This is where the fracas and angst, albeit politely, comes into play:

VMa{VDIα … VDIΩ} ≈ VMb{VDIα…VDIΩ} ∴ VMb is a BACKUP!


(or in English)


Most certainly, I make snapshots from time to time for various reasons: from testing to taking a quick snapshot before I make major changes to my VMs. If something goes awry or if I so desire, I can revert back to the snapshot and pick up as if nothing happened to my VM.

With regards to XenServer, much work has and still is being done with snapshots and… coalescing.

Coalescence can be, under the field of computers, defined as:

The joining of adjacent data to fill gaps: forming a contiguous segment that had previously been fragmented

In other words, every time a snapshot is made of a VM a difference disk is left behind and the product is a new virtual disk to resume current VM operations (until the next snapshot). Where a VM has multiple snapshots, rest assured these are in order and have a corresponding parent. This, kiddos, is a “snapshot chain” and even it has its mathematical limits. I recommend never going over 24-28, but then again, I never recommend double-digit snapshots for a single VM!

If one should ever exceed 30 snapshots, the mathematics for virtual disks, or VHDs (a standard set by Microsoft), means that a snapshot chain – from 30, 29, 28, and onto the base disk – can’t collapse. The only recourse is to export the VM (truncating the useless snapshots, but making a copy of the active VM disks and memory).

“What if I only have a few snapshots and I just delete them?”

Great question, Johnny, as this is where coalescing really comes into play.

Consider that with most hypervisors, snapshots are created and deleted against live, running VMs.  This means some pretty clever work has to go into:

  • Flagging snapshots Johnny has marked for deletion
  • Identifying parent/chain members
  • Analyze the most recent snapshot
  • Coalesce the changes into its parent (snapshot)
  • Repeat the process until the desired snapshots are coalesced into themselves or, if all snapshots are deleted, into the original virtual disks the VM began with

This may not seem so bad since (for the most part) snapshots are sparse, or not the full size of the original VM disks: just a a delta in changes. However, what if you have a 1TB disk, a snapshot and 750GB of changes? Well, it means there is roughly 1.750TB of data to man handle WHILE the VM runs during the coalesce process.

This can take time based on man factors: speed of storage, burden on the host and quantity of snapshots with X amount of size.

Just like the reverse of a snapshot, a virtual disk is created to hold the coalescing of a snapshot with its parent. Only when it is complete, the snapshot is deleted. With multiple snapshots this process repeats and can wax and wane on storage consumption at the physical level.

To bring an abrupt ending to this as to point to resources online that further explain this:

Be careful how many snapshots of sizable disk you make! You may find yourself short on space for the time being as checks and balances are being looked at in the Xen/XenServer world.

The following articles – old and new for various reasons – explain how snapshots and coalescing works, as well as ways to troubleshoot potential coalescing issues for XenServer:

No, I didn’t write these and if you did, please let me know for attribution!

–jkbs | @Xenfomation |


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s