Virtualization, High Performance Computing, Healthcare IT, Enterprise Computing
There are variety of factors that influence the speed of cloning from a template, this post is to highlight some of the big wins if you are having issues.
Read the VMware kb article 1004002 and 1004028
Templates should be in their own datastore. – A Best Practice
By storing templates in their own datastore the read intensive I/O ( reading template ) is separated from the write intensive I/O ( writing new VM from template ). With NFS in particular, ESX only uses one TCP stream per datastore, so by using different datastores ( a best practice) the time to create a VM from a template may be reduced.
Thick and eager zero – The slow boat to China
Don’t deploy your VM to be thick and eager zero, deploying thick and eager zero will be MUCH slower than thin or zero thick.
Simply not enough spindles. – The immutable laws of Physics
Creating a VM from template is intense, you are reading the template and writing a new VM both of which are single large block sequential I/O stream operations. If you simply don’t have enough spindles, the amount of I/O you can push will be limited. Going forward Solid State Drives (SSD’s) may eliminate the issue of “spindle count”.
Utilize Your Storage Array
Cloning at the storage array level can be near instantaneous, for example NetApp has their Rapid Cloning Utility RCU. If you don’t have array support, there are multiple other ways to tune your storage assuming you have sufficient spindles, like write caching, stripe size, RAID choice, and so on. This is vendor specific to some degree and beyond a 5 tips article. If you are on ESX 3.5 ( not vSphere) see VMware kb article 1003469 for a I/O tunable that can help speed up large block disk I/O.