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:ilya.mailing.li...@gmail.com] Sent: Thursday, June 12, 2014 2:18 AM To: users@cloudstack.apache.org 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 > >
