5. vCloud Resource Design : 5.4 Organization Virtual Datacenters : 5.4.3 Fast Provisioning
   
5.4.3 Fast Provisioning
Fast provisioning allows rapid provisioning of vApps through vSphere 5 linked clone technology. A linked clone uses the same base disk as the original, with a chain of delta disks to keep track of the differences between the original and the clone. By default, fast provisioning is enabled when allocating storage to an organization virtual datacenter. Disabling fast provisioning on organization virtual datacenters means that full clones are created for subsequent vApp deployments.
Fast provisioning benefits include the following:
*Increased elasticity – The ability to quickly provision vApps from a catalog using linked technology allows vCloud applications to scale up as needed.
*Increased operational efficiency – Use of linked clones typically results in significant improvement in storage utilization.
Fast provisioning includes the components:
*Linked clone – Virtual machine created as a result of a copy operation, leveraging a redo-log-based linked clone from the parent.
*Shadow VM – Full copy of the primary virtual machine used as the source for linked clone creation. A shadow virtual machine allows cross-datastore provisioning and is transparent to end users. Shadow virtual machines are created for vApp templates only, not for MyCloud vApps.
During fast provisioning, vApp files can reside on the same virtual datacenter as the primary virtual machine or a different virtual datacenter. The choice of destination virtual datacenter impacts fast provisioning deployment based on the associated datastores and vCenter Server instances, as shown in the following table.
Table 9. Linked Clone Deployment
Source vCenter
Target vCenter
Source Datastore
Target Datastore
Shadow VM
VC1
VC1
DS1
DS1
Not created until linked clone depth limit is reached (default = 31).
VC1
VC1
DS1
DS2
Created on DS2 and registered on VC1.
VC1
VC2
DS1
DS1
Created on DS1 and registered on VC2.
VC1
VC2
DS1
DS2
Created on DS2 and registered on VC2.
 
Both source and target virtual datacenters have fast provisioning enabled. Linked clones created from VC1 use the primary virtual machine as the base disk. Linked clones created from VC2 use the shadow virtual machine as the base disk.
The following are considerations for fast provisioning:
*Separate the datastores reserved for fast provisioning from the datastores reserved for full clones to improve performance and manageability.
*Fast provisioning requires vSphere 5.x.
*Fast provisioning is supported by vSphere Storage DRS with vCloud Director 5.1.
*Datastore selection is determined by vSphere Storage DRS when using VMware vCenter 5.1.
*Provisioning time is nearly instantaneous when provisioning to the same datastore.
*Using VMFS5 datastores removes the 8-host limit for fast provisioning (32-host maximum).
*Using VMFS3 datastores enforces an 8-host limit for fast provisioning.
*Provisioning a virtual machine to a different datastore triggers creation of shadow virtual machines if one does not already exist on the target datastore.
*Shadow virtual machines are full copies of the source virtual machines, which factors into sizing considerations for pre-provisioning shadow virtual machines across datastores.
*Storage array caching can boost linked clone performance. Ample storage array cache greatly benefits an environment that uses linked clones.
*Although there is no limit to the width of a tree, datastores can fill up if a tree gets too wide. Use cross-datastore linked clones to mitigate this issue.
*The maximum linked clone chain length is 30. Further clones of the vApp result in full clones.
*Shadow virtual machines are treated differently from normal virtual machines and can be referenced through the vCloud API by the SHADOW_VM entity type.
*Invoke vSphere Storage vMotion migration of linked clones only through the vCloud API (Relocate_VM call). The target virtual datacenter must have visibility to the datastore that contains the source disks.
*Do not invoke vSphere Storage vMotion operations on linked clones through the vSphere Client, as doing so consolidates the linked-clones and might result in inconsistent behavior.