Hmm, for me linked clones cause slow downs with aggressive Pre/post deduplication.
I agree that it should be a cluster switch. Perhaps housed in a service offering and using the tagging system? But yes, any less granular then a cluster and we could run into issues for being too restrictive. -kd Sent from my iPhone On Dec 21, 2012, at 9:10 AM, "Musayev, Ilya" <imusa...@webmd.net> wrote: > Tamas > > There are cases where you want to have flexibility between running full or > linked clone and the global switch maybe too inflexible. > > Pros for linked clone > if you environment is truly cloud ready, when you scale horizontally - you > want to be able to spin up vms in seconds to accommodate the rapid load. With > linked clones, I can spin up vms in 20-30 seconds on slow nfs store. > It's also good when you have small but highly reliable datastore > The disk locking and contention issues are things of the past with VMFS5 and > VAII support. > > With full clones - your mileage will vary depending on the backend storage. > > While it is good to have reliable storage like full clone, there are some > instances when it does not really matter. > > Also, it's CS admin responsibility to have reliable backend storage to avoid > corruption, maintain back-up of templates and version control your templates > to avoid overwrites. > > Any thoughts? > Ilya > > Tamas Monos <tam...@veber.co.uk> wrote: > The end user will have no idea what linked-in or full clone means so I would > recommend not to reflect this to the end user in any way especially in the > deployment wizard. > There should be a global option for this and the deployment api would use > that value. Only admins should be able to change cloning behaviour. > > Regards > > Tamas Monos DDI > +44(0)2034687012 > Chief Technical Office > +44(0)2034687000 > Veber: The Hosting Specialists Fax +44(0)871 522 7057 > http://www.veber.co.uk > > Follow us on Twitter: > www.twitter.com/veberhost<http://www.twitter.com/veberhost> > Follow us on Facebook: > www.facebook.com/veberhost<http://www.facebook.com/veberhost> > > > -----Original Message----- > From: Musayev, Ilya [mailto:imusa...@webmd.net] > Sent: 21 December 2012 07:47 > To: cloudstack-dev@incubator.apache.org > Subject: Re: [PROPOSAL] Raise cluster size limit to 16 on VMware > > If I can propose a solution. > > 1) extend vm create api to have an option like "linkedclone = 0" to do > traditional full clone or set it to 1 to make it linked. Either 1 or 0 set to > default. > > 2) add a feature in instance deployment wizard to do a full or link clone > triggering the api call referenced above. > > any thoughts? > > Kelven Yang <kelven.y...@citrix.com> wrote: > Converting linked-clone to full clone is doable. > > Kelven > > On 12/20/12 11:17 AM, "Anthony Xu" <xuefei...@citrix.com> wrote: > >> Linked clone is fast, it can decrease the VM provision time. >> Full clone improves disk access performance. >> >> Not share if VMware provide API to convert linked clone to full clone? >> >> If yes, should we consider following? >> Virtual disk starts with linked clone( fast VM/Disk provision). >> Convert linked clone to full clone later if needed >> >> >> Anthony >> >> >> >> >>> -----Original Message----- >>> From: Hari Kannan [mailto:hari.kan...@citrix.com] >>> Sent: Thursday, December 20, 2012 10:55 AM >>> To: cloudstack-dev@incubator.apache.org >>> Subject: RE: [PROPOSAL] Raise cluster size limit to 16 on VMware >>> >>> I have no voting power either... I proposed to add this feature >>> (didnt know there was an existing proposal) yesterday >>> >>> Hari >>> ________________________________________ >>> From: Musayev, Ilya [imusa...@webmd.net] >>> Sent: Thursday, December 20, 2012 1:50 PM >>> To: cloudstack-dev@incubator.apache.org >>> Subject: RE: [PROPOSAL] Raise cluster size limit to 16 on VMware >>> >>> Though I have no voting power, I agree we should have a config >>> setting for using linked clone or traditional clone. >>> >>> -----Original Message----- >>> From: Hari Kannan [mailto:hari.kan...@citrix.com] >>> Sent: Thursday, December 20, 2012 1:37 PM >>> To: cloudstack-dev@incubator.apache.org >>> Subject: RE: [PROPOSAL] Raise cluster size limit to 16 on VMware >>> >>> +1 on making linked clones optional >>> ________________________________________ >>> From: Tamas Monos [tam...@veber.co.uk] >>> Sent: Thursday, December 20, 2012 1:01 PM >>> To: cloudstack-dev@incubator.apache.org >>> Subject: RE: [PROPOSAL] Raise cluster size limit to 16 on VMware >>> >>> Sorry for the side-track for a moment but just another reason to get >>> rid of linked-in clone template management on vmware in the long-run. >>> I still do not believe using linked-in clones is actually beneficial >>> taking into account it drawbacks: >>> https://issues.apache.org/jira/browse/CLOUDSTACK-529 >>> >>> Regards >>> >>> Tamas Monos DDI >>> +44(0)2034687012 >>> Chief Technical Office >>> +44(0)2034687000 >>> Veber: The Hosting Specialists Fax +44(0)871 522 >>> 7057 >>> http://www.veber.co.uk >>> >>> Follow us on Twitter: >>> www.twitter.com/veberhost<http://www.twitter.com/veberhost<http://www.twitter.com/veberhost<http://www.twitter.com/veberhost>> >>> Follow us on Facebook: >>> www.facebook.com/veberhost<http://www.facebook.com/veberhost<http://www.facebook.com/veberhost<http://www.facebook.com/veberhost>> >>> >>> >>> -----Original Message----- >>> From: Alex Huang [mailto:alex.hu...@citrix.com] >>> Sent: 20 December 2012 16:50 >>> To: cloudstack-dev@incubator.apache.org >>> Subject: RE: [PROPOSAL] Raise cluster size limit to 16 on VMware >>> >>> Kelven offered a reason earlier. >>> >>> "8-host limitation comes from the limitation posted from VMFSv3 for >>> linked-clone usage. So in CloudStack, it is an artificial limit we >>> post to reduce possible runtime problems." >>> >>> It's due to VMFSv3 and usage of linked clone in CloudStack. >>> >>> --Alex >>> >>>> -----Original Message----- >>>> From: Chip Childers [mailto:chip.child...@sungard.com] >>>> Sent: Thursday, December 20, 2012 8:46 AM >>>> To: cloudstack-dev@incubator.apache.org >>>> Subject: Re: [PROPOSAL] Raise cluster size limit to 16 on VMware >>>> >>>> On Thu, Dec 20, 2012 at 10:24 AM, David Nalley <da...@gnsa.us> wrote: >>>>> On Thu, Dec 20, 2012 at 1:54 AM, Koushik Das >>>>> <koushik....@citrix.com> >>>> wrote: >>>>>> This http://www.vmware.com/pdf/vsphere5/r51/vsphere-51- >>>> configuration-maximums.pdf mentions that the max. can be 32 for ESX >>> 5.1. >>>> Any specific reason to make it 16? Also it needs to be seen that >>>> this limit works across all supported ESX versions. >>>>>> >>>>>> -Koushik >>>>>> >>>>> >>>>> Yes - the different versions having different limits complicates >>> things a bit. >>>>> 5.1 = 32, 5.0 = 16 4.x = 8? >>>>> >>>>> --David >>>>> >>>> >>>> 4, 5 and 5.1 are all 32 hosts per cluster. Raw metrics, not using >>>> a more complex algo to calculate the more realistic cap. Just >>>> curious, but are there more specific reasons that we are talking >>>> about 4.x having a lower number? >>>> >>>> http://www.vmware.com/pdf/vsphere4/r40/vsp_40_config_max.pdf >>>> http://www.vmware.com/pdf/vsphere5/r50/vsphere-50-configuration- >>>> maximums.pdf >>>> http://www.vmware.com/pdf/vsphere5/r51/vsphere-51-configuration- >>>> maximums.pdf >>>> >>>> -chip >>> >>> >>> >> > > >
