When the full clone feature was initially introduced, i asked if full
clone - can be per cluster or even per VM level. Unfortunately no-one
listened :(
These days, this inflexibility becomes very annoying. You can copy the
parent vmdk from another datastore or from secondary store - its just an
annoyance and downtime to end users.
Considering that 95% of work has already been done to support full
clones, extending it to a cluster level - should not be too hard. I will
kindly ask Citrix to consider putting it on the roadmap.
On 6/12/14, 8:18 PM, Steve Searles wrote:
It would also be nice to define this on the cluster or at least the zone level
rather than being an all or nothing global setting.
Steven Searles, CTO | [email protected]
Zimcom Internet Solutions | www.zimcom.net
O: 513.231.9500 | D: 513.233.4130
-----Original Message-----
From: Steve Searles [mailto:[email protected]]
Sent: Thursday, June 12, 2014 11:07 PM
To: [email protected]
Subject: RE: Vmware Full Clones vs Linked Clones
Very infomitive explination, thanks for taking the time. We use VMAX and VNX
storage with FAST-CACHE/FASTVP, I would almost rather burn the storage on the
vmware VM's for full clones after reading your explination and let the lighter
loaded vm's use KVM or XEN which seem to behave in a similar manner. I would
hate to loose a whole set of enterprise servers over a single mishap with the
snapshot chain. There is also the issue of resizing the ROOT disk which does
not seem to be possible with linked clones, (understandably so). It will be
nice when root disk resizing is implemented in CS rather than changing the disk
in vmware and manually updating the DB.
Thanks Again,
Steve Searles
-----Original Message-----
From: ilya musayev [mailto:[email protected]]
Sent: Thursday, June 12, 2014 2:18 AM
To: [email protected]
Subject: Re: Vmware Full Clones vs Linked Clones
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
