Uncategorized

Faster Cloning Time Or Semi-Automated Space Reclamation – Revisited.

Readers of my blog knows that we typically reccemdend using Eager Zeroed thick VMDKs for performance, the performance aspect of it will manifest as a faster cloning time and a faster performance during the initial writing blocks inside the VM..


 

It’s a good thing that the times are changing, recommended practices are always being revised because technology itself is changing, how does it related to Eager zeroed thick VMs?

With vSphere 6, VMware introduced a semi-automated mechanism to reclaim capacity from VMs, if you are not familiar with space reclamation and why it is an absolute must on AFAs, a good place to start will be in a post I wrote here

https://itzikr.wordpress.com/2014/04/30/the-case-for-sparse_se/

so again, in vSphere 6, there is a way to run space reclamation on VMs

https://itzikr.wordpress.com/2015/04/28/vsphere-6-guest-unmap-support-or-the-case-for-sparse-se-part-2/

but the BIG but is that UNMAP only works when

* unmap of deleted blocks with in VMFS (i.e vmdk deletion, swap file deletion etc), for this you can use the EMC VSI plugin.

* Smaller unmap granularity. With existing VMFS version, the minimum unmap granularity is 1MB.

* Automatic UNMAP for support for windows version less than Windows 8 / server 2012 (no linux support)

* the device at the VM level (the drive) must be configured as “thin”, not “eager zeroed thick” or “lazy zeroed thick”

So while it is awesome that you can now almost forget about running space reclamation manually, you are still faced with a big dilemma, should I change my VMs VMDK format to “thin” which is a pre-requisite for automated UNMAP or should I stick with eager zeroed thick for performance?

You CAN have your cake and eat it to, here’s what you need to do

Below you can see a windows 10 VM that I prepared,

The Windows 10 VM was allocated a 40GB drive

 

Which out of the 40GB, only 16.6GB were actually used.

I then cloned the VM to 2 templates, the first one was cloned to a thick eager zeroed template and then I cloned the VM to a template that was based on “thin” vmdk.

I then had two templated looking like this

I then deployed a VM from the eager zeroed thick template, the cloning took:

14 seconds

You can also see the IOPS used, red means the beginning of the cloning operation, green means the time it ended.

And the bandwidth that was used

With that I moved on deploying a VM from the thin VMDK based template

the cloning took:

09 seconds

You can also see the IOPS used, red means the beginning of the cloning operation, green means the time it ended.

 

And the bandwidth that was used

 

 

And here’s how it looks if you compare the bandwidth between the two cloning operations, again, they were both deployed from the same windows templates, the only difference is that was template was thin and the other was egaer zeroed thick

 

So the question is why, why would a thin based deployment takes LESS time than an eager zeroed thick, it used to be the exact opposite!

The “magic” is happening because when I initially install windows on that VM, I then CLONED it to a template which defrag the data inside the VM, yes, I also cloned that VM to an eager zeroed thick template but now the data was structured in a much better way so the fact that the thin template had less capacity as it is thin, now means less time to deploy!

So..

Clone you VMs to a thin template, enable running space reclamation on the OS’s that support it (windows 8/8.1/10 / Server 2012/2012 R2/2016 and enjoy both worlds!

Categories: Uncategorized

Leave a Reply

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

WordPress.com Logo

You are commenting using your WordPress.com 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 )

Google+ photo

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

Connecting to %s