This topic comes up many times, it all depends what backend storage,
number of spindles, workload type and SLAs during issues.
Linked Clones
Pros:
VM comes up online within 1 minute or less (2 minutes if you are running
slower backend storage)
You are saving on diskspace, if the rate of change on ROOT is small and
data does NOT reside on ROOT volume
If you storage uses FAST technology and moves frequently accessed data
blocks to something like SSD, initial boot up time improves greatly
Cons:
You are leveraging VmWare Snapshot technology and changes are written in
the form of deltas, which means if you create a 5GB file and delete it,
your vmdk delta file will still be 5GB in size and will most likely only
grow,
Corruption to a parent vmdk on the primary datastore will impact other
VMs that are dependent on it - hence reliable storage is needed.
Perfomance may degrade overtime if rate of change is high - also pending
your storage backend
Snapshotting (using vmware snapshot feature), will work, but if you have
a complex snapshot three and some delta vmdk under this tree get
corrupted, you may loose your data (until good working state) - this
issue applies to snapshots in general
Full Clones:
Gets your independent disks with no delta complexity, at the expense of
extra storage and some IO if you dont have FAST technology enabled.
Corruption to a vmdk file, affects only 1 VM.
If the VM has heavy read and write IO, you should consider running it as
full clone as you will avoid delta complexity.
There are probably more reasons, just cant think of them now,
Regards
ilya
On 6/11/14, 7:42 AM, Steve Searles wrote:
Can someone speak about using Linked Clones vs Full Clones in a production CS
environment? What is the performance impact on the parent virtual machine?
What type of density can be expected if all the child vm’s are performing read
operations from the same snapshot of the parent VM? What are the dangers of
using linked clones in this manner? What are the best practices from the CS
community?
Steve Searles
