You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cloudstack.apache.org by Steve Searles <ss...@zimcom.net> on 2014/06/11 16:42:03 UTC
Vmware Full Clones vs Linked Clones
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
Posted by Erik Weber <te...@gmail.com>.
On Wed, Jun 11, 2014 at 4:42 PM, Steve Searles <ss...@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
Re: Vmware Full Clones vs Linked Clones
Posted by ilya musayev <il...@gmail.com>.
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 | ssearles@zimcom.net
> Zimcom Internet Solutions | www.zimcom.net
> O: 513.231.9500 | D: 513.233.4130
>
>
>
> -----Original Message-----
> From: Steve Searles [mailto:ssearles@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.lists@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
Posted by Steve Searles <ss...@zimcom.net>.
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 | ssearles@zimcom.net
Zimcom Internet Solutions | www.zimcom.net
O: 513.231.9500 | D: 513.233.4130
-----Original Message-----
From: Steve Searles [mailto:ssearles@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.lists@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
Posted by Steve Searles <ss...@zimcom.net>.
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.lists@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
Posted by ilya musayev <il...@gmail.com>.
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
>
>