VDI: A Guide to VMware Provisioning Technologies

Whether you're just getting started with VDI or have years of experience under your belt, one of the more challenging concepts to grasp is how the provisioning technologies work and their impacts. If you have previous experience with Citrix, I'd recommend reviewing one of our previous articles where we outlined similar components and functionalities between Citrix and VMware's VDI solutions. If you're coming in with a clean slate, well, here we go.

What is VMware Provisioning Technology?

A provisioning technology can be simply described as the method used to create new instances of a machine's configuration that serve as dependent, yet fully functional copies of their originating machine's setup. The purpose is to provide IT administrators with the capability of deploying, updating, and managing tens, hundreds, and even thousands of downstream machine changes by making the change on the parent machine and pushing them out. In the world of VDI, this is a critical function. It allows for increased consistency across the environment as well as assured compliance.

What are Your VMware Provisioning Options?

VMware's provisioning technologies offerings provide relatively the same outcome. However, they accomplish this with subtly different underlying technologies. At the time of this writing the current release of VMware's VDI offering is Horizon 7.12. Horizon 7.12 supports the following options for provisioning:

• Manual

• Linked Clones

• Instant Clones

Collectively, these options will meet most organizations' needs without question. Let us continue onto our assessment of each.

Manual VMware Provisioning: Creating VMs

Manual provisioning refers to creating virtual machines (VMs) by either manually installing/configuring an OS onesy-twosy or by cloning an existing VM to create additional copies of a desired machine. Either way this methodology leaves virtual machines disjointed: changes made on one are not reflected on cloned or otherwise virtual machines that may make up a pool.

This becomes a management nightmare as without a constant baseline with which to reference or return to, machines quickly experience configuration drift. This configuration drift makes each VM its own unique snowflake, which, in the event of issues, increases troubleshooting complexity. This is the least ideal methodology for deploying VDI.

VMware Link Clones: Dependently Linked to Upstream Images

Before we get into any tech details, let us set the stage here a bit. In the late 2000s, the vast majority of the desktop and application virtualization market share was held by Citrix with very few threatening incumbents. Citrix's bread-and-butter was their application virtualization platform that was only strengthened by their PVS provisioning technology that enabled administrators to scale quickly. Being the juggernaut of the server virtualization market, VMware had developments at the hypervisor level that they knew if adapted for VDI workloads could change the market. With this in mind VMware View was launched with the linked clone technology ushering in VMware's encroachment on the VDI marketplace.

So what are linked clones? Kudos to VMware for such a well-suited name, but they are essentially just that, clones of a virtual machine dependently linked to an upstream base image for changes and/or updates. To illustrate how they work we will use the following depiction.

The process begins by creating a VM in your hypervisor of choice, setting it up as desired with your required operating system, applications, and their necessary configurations. Once the image is in the desired state, a snapshot is taken to capture the point-in-time configuration. This is known as your master image. From there a component of Horizon called View Composer instructs the hypervisor to copy a consolidated image of the base and snapshot into what's known as a replica disk. This replica disk is then copied out to all storage volumes that are setup for your Horizon configuration in preparation for VDI provisioning.

Linked clones are made up of three disks: a replica disk, an internal disk, and a delta disk. The replica disk acts as a read-only source for the VDI's base configuration. The internal disk stores the machine password and maintains the machine's persistence through refreshes.

So what is a refresh? A refresh is a mechanism to return a linked clone machine back to its initial configuration at the time of creation. With the combination of a replica and identity disks, the one other thing a machine needs is somewhere to store its writes. The delta disk houses all writes from the time of boot up including, but not limited to application changes, logs, temporary files, any user changes, etc. At the time of initial provisioning a snapshot is taken, which provides a point-in-time state to which the refresh operation can revert. In non-persistent scenarios where users access random machines this comes in handy as machines can quickly be reverted to their initial setup upon logoff making way for a clean user experience for the next user.

A full detailed explanation of the provisioning methodology can be found on VMware's KB Article on Linked Clones.

VMware Instant Clones: Highly Integrated with vSphere

Story time again! Within a few years of VMware's revolutionizing the VDI landscape with its linked clone technology, Citrix returned fire with an eerily similar approach in their Machine Creation Services (MCS) technology that is nearly identical to the linked clones approach. The big game changer here though was that Citrix implementation of a storage-driven provisioning technology was not limited to a particular hypervisor, but rather hypervisor agnostic.

This flexibility granted Citrix's customers freedom to use whichever hypervisor they wished and unfortunately VMware's vSphere licensing costs were already a deterrent for many customers. In order to attract customers, a differentiator would be needed that would set VMware apart from the proverbial pack. Enter instant clones.

Internally developed as VMFork, Instant Clone is aptly named as downstream machines can be updated as quickly as they can complete a typical reboot cycle. To accomplish this let's examine the VMFork technology in more depth. Note, this technology is highly integrated with vSphere, VMware's virtualization platform, and as such evolves with each version release, but we'll be examining the vSphere 6.7 release.

Looking at this illustration you may think the creation process of instant clones resembles more that of the Immaculate Conception, but fear not as we can break it down into a few general steps.

1. The process begins with the same familiar steps of setting up a master image and taking a snapshot to capture the point-in-time desired configuration.

2. Next an Internal Template VM is created, which A) performs a domain-join function and B) is used to create the subsequent replica VMs.

3. The Replica VM is very similar to that of the linked clone replica VMs and will serve as the read-only disk for any downstream instant clones created.

4. From there, Parent VMs are populated onto each host and data store combination identified in the instant clone's pool configuration. Parent VMs stay in a powered on state and serve as the creation point for any instant clones residing on that particular host and data store.

5. Lastly, instant clones are created using the active memory and disk of the Parent VM. Once created, the instant clone begins to reference the Replica VMs read-only disk and writes go to a delta disk stored where the instant clone resides.

The key here to the VMFork technology is the Parent VM's ability to capture the Replica VM's memory and disk state allowing instant clones to provision in seconds as boot times are essentially eliminated. Along the same lines, considering that instant clones spawned from a Parent VM are completely independent after they are created, Parent VMs can be deleted without affecting existing instant clones.

Another interesting evolution in VMFork is that with recent releases of vSphere, slight adjustments have been made to some of the technical details between steps 4 and 5 identified above. In short, by freezing the Parent VM, rather than leaving it in a fully running state, and slightly changing how the delta disks for instant clones were stored, greater capacity and performance were achieved with the instant clone technology. William Lam's article New Instant Clone Architecture in vSphere 6.7 provides a brilliant write-up on this that sheds some much needed light on the topic.

VMware VDI Product Comparison

Considering the instant clone technology was developed as VMware's response to market concerns on the limitations of linked clones, it's quite easy to recognize some immediate enhancements over its predecessor. The big keywords that come to mind when considering said advancements:

1. Scalability

2. Capacity

3. Speed

4. Performance

The big concern often highlighted with linked clones is the inability to scale in large enterprise environments where not hundreds, but thousands of machines are required. Prior to the mass acceptance of flash-storage, storage arrays were largely measured on their Input-Output-Per-Second (IOPs). High IO operations, such as updating a pool of hundreds of VMs, could easily overcome the storage appliances performance threshold thus building an IO queue and increasing latency. Operations of this nature could take hours to complete and for some market segments, this was unacceptable.

Building upon linked clones' ability to share replica disks, instant clones enable the sharing of memory in such a way that increases the density of VDIs per host, reduces provisioning and boot-time, and eliminates boot storms. To understand the importance of these items you must think like a VDI engineer and understand that these are the boogie-men (or Baba Yaga, if you prefer) that keep engineers awake at night. Addressing these three concerns of its predecessor, instant clones become the clear front-runner for many a VDI engineer.

Architecture-wise, instant clones' underpinnings are a bit more complex than linked clones, which make it a bit more cumbersome to troubleshoot. For starters, all relevant VMs in a chain (internal templates, replicas and parent VMs) are inaptly named with GUIDs rather than a pool name or "human-readable" alternative. Other common complaints include an inability to gather View Agent logs as the "instant" portion of instant clones live up to its name by speedily terminating and re-building faulty machines. Often times with this approach, it's necessary to either A) engage VMware support, B) edit a Pool setting in the Horizon View ADAM database, or C) perform some advanced troubleshooting by enabling a debug mode on the master VM in order to triage. One of the key benefits is that with instant clones, a View Composer server is no longer needed, which inherently means a View Composer database is not required as well. For many, this fact alone will be reason enough to adopt the new standard.

I'm sure you are getting the gist. As the new kid on the block instant clones have some formidable advantages. But what about downsides? Well, instant clones do have a list of restrictions, but impressively these are shrinking with each release as it's obvious VMware is pouring some serious development cycles into the underlying VMFork technology — not just for VDI but for their flagship vSphere product as well.

So what are some of the scenarios where you'd potentially want to run linked clones?

• You have a reliance on persistent disks that AppVolumes cannot address.

• You need Windows 8 or 8.1 VDis.

• You are still using Persona Management (VMware's legacy profile management solution).

Previous versions of instant clones had additional limitations such as incompatibility with static IPs, incompatibility with IPv6, and inability to delay image updates. Note, all of these are now allowed with the Horizon 7.12 release and vSphere 6.7.

Final Thoughts

Overall, instant clones will fully replace the legacy technology of linked clones someday, but for now there has not been an official End-of-Support announcement. Until then, for those running linked clones, I'd suggest preparing for the future migration with any of the articles referenced above or with some supplemental Horizon 7 training courses. I hope this article makes your selection process or migration project a bit easier and best of luck to you!