There will be occasionally some cases that user may need to be aware of the differences of these two underlying implementations, in cases that users want to build auto-scale application servers, fast-provisioning linked-clone would be a preferable choice for them. Stateless application servers are very suitable to be launched quickly in this way.
I think it may not be a bad idea for end-user to be aware of these concepts. There are eventually two essential parts to make the solution reliably. First from infrastructure level, we probably need to manage a planned usage of linked-clone for a host cluster, since physical restrictions in ESXi 4/4.1/5.0 do exist, second, from end user perspective, we probably need to expose this feature explicitly so that user can be in the driver seat. Kelven On 12/21/12 2:46 AM, "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 >Follow us on Facebook: 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> Follow us >>>on Facebook: >>> 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 >>> >>> >>> >> > > >
