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
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: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
RE: Vmware Full Clones vs Linked Clones
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 | ssear...@zimcom.net Zimcom Internet Solutions | www.zimcom.net O: 513.231.9500 | D: 513.233.4130 -Original Message- From: Steve Searles [mailto:ssear...@zimcom.net] Sent: Thursday, June 12, 2014 11:07 PM To: users@cloudstack.apache.org 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: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
Re: Vmware Full Clones vs Linked Clones
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 | ssear...@zimcom.net Zimcom Internet Solutions | www.zimcom.net O: 513.231.9500 | D: 513.233.4130 -Original Message- From: Steve Searles [mailto:ssear...@zimcom.net] Sent: Thursday, June 12, 2014 11:07 PM To: users@cloudstack.apache.org 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: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
Re: Vmware Full Clones vs Linked Clones
On Wed, Jun 11, 2014 at 4:42 PM, Steve Searles ssear...@zimcom.net 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? Never did any performance measurements, but I do recall that there were more times I regretted to be using the feature than otherwise. Unfortunately I don't recall why, as we've left VMWare with CloudStack and are now running XenServer. -- Erik Weber
