Feature: Configurable setting to use linked clones or not

Background: Customers have filed Enhancement Request regarding linked clones as the default choice in CS as they can limit cluster size and have other undesirable side effects as well. This should be a configurable option as some customers said that they would continue to use linked clones in specific scenarios. Some of the limitations are due to the way we implemented VMware support in CS, others are inherent to linked clones functionality, in general.

-          Read hotspots for too many VMs based on the same VM root template

-          Each datastore in the cluster has to have its own copy of the template

-          Cluster size limits imposed initially by VMWare (no longer an issue but CS has 8 hosts in a cluster limit) for linked clones

-          Some backup products had issues with linked clone copy restores but that would be more of the 3rd party product issue

-          Accidental deletion  of root template will render all the VM instances depending upon the root template to be useless (has happened at a customer site)

-          If there is a corruption in the root then the all the linked clones are rendered corrupt. Some customers mentioned that even if one of the clones is corrupt then the entire set is rendered corrupt (I wasn't sure if that is accurate or not). Some say that even when they know that there is no corruption in the root, vSphere concludes there is corruption and forces the VMs to be recreated

Many customers' input is that in situations where they care about the speed of VM deployments they may use the link clone feature, but in several other situations where they could either provision in advance or could simply bear the provisioning time for all the benefits. Ideally, CS would support both the models and the customer would be given the option of choosing which one he wants to use

Requirement:

-          Support a configurable way to choose between linked clones and full clones

-          make it part of the service offering; like local storage. Admin has to configure it, but user gets the option of choosing it (Community choice) i.e. the admin (Operator) will first have to make this an option of the service (compute) offering if he want to provide this. Then the end-user gets to choose if he wants it or not

Open Questions:

- how long will the template be stored in primary if the deployments of a VM in a cluster are all non-linked clones? Any optimization can be done here, in terms of deletion and retrival?

- If the ability to request a linked vs. non-linked clone is tied to a service (compute) offering, how do we deal with different hypervisor capabilities? i.e. if KVM or OVM dont support this, but the user selects linked clone option - do we just "silently" ignore this?

- If a VM is created as a linked clone, there is no need to make it non-linked clone afterwards (or vice-versa)

- similarly, if upgrading from 4.0 to 4.1, VMs created in 4.0 (linked clones) dont need to be allowed to become non-linked clones

- after introduction of this capability, for usage/billing purposes, there must be a mechanism to inform that a VM is using linked vs. non-linked clones (premium service will provide non-linked clones and charge extra, for example)