VDI: A Guide to VMware Provisioning Technologies

Whether you're just starting with VDI or have years of experience, one of the more challenging concepts is how provisioning technologies work and their impacts. If you have previous experience with Citrix, I recommend reviewing one of our last articles, in which we outlined similar components and functionalities between Citrix and VMware's VDI solutions. If you're coming in with a clean slate, here we go.

What is VMware Provisioning Technology?

A provisioning technology can simply 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 and 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 our assessment of each.

Manual VMware Provisioning: Creating VMs

Manual provisioning refers to creating virtual machines (VMs) by manually installing/configuring an OS onesies-two or cloning an existing VM to create additional copies of a desired machine. Either way, this methodology disjointed virtual machines: 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; machines quickly experience configuration drift. This configuration drift makes each VM its 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. In the late 2000s, Citrix held the vast majority of the desktop and application virtualization market share with very few threatening incumbents.

Citrix's bread-and-butter was its application virtualization platform, which was only strengthened by its PVS provisioning technology, which 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 updates. To illustrate how they work, we will use the following depiction.

The process begins by creating a VM in your hypervisor of choice and 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 captures the point-in-time configuration.

This is known as your master image. From there, a Horizon component called View Composer instructs the hypervisor to copy a consolidated image of the base and snapshot into a replica disk. This replica disk is then copied to all storage volumes that are set up for your Horizon configuration in preparation for VDI provisioning.

Linked clones consist of three disks: a replica disk, an internal disk, and a delta disk. The replica disk is 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 to its initial configuration at the time of creation. With the combination of 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, including, but not limited to, application changes, logs, temporary files, any user changes, etc.

When initial provisioning, a snapshot is taken, which provides a point-in-time state from 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, creating a clean user experience for the next user.

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 was that Citrix's implementation of a storage-driven provisioning technology was not limited to a particular hypervisor but rather a hypervisor agnostic.

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

Internally developed as VMFork, Instant Clone is aptly named because 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 that 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—we can break it down into a few general steps.

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

2. Next, an Internal Template VM is created, in 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 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 parent VM's active memory and disk. Once created, the instant clone begins to reference the Replica VM's read-only disk, and writes go to a delta disk stored where the instant clone resides.

The key to the VMFork technology is the Parent VM's ability to capture the Replica VM's memory and disk state, allowing instant clones to be provisioned in seconds as boot times are 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 fascinating 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, the instant clone technology achieved greater capacity and performance. William Lam's article New Instant Clone Architecture in vSphere 6.7 provides a brilliant write-up that sheds some much-needed light on the topic.

VMware VDI Product Comparison

Considering that instant clone technology was developed as VMware's response to market concerns about 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.

Before 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; this was unacceptable for some market segments.

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 know 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, making troubleshooting a bit more cumbersome. 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. With this approach, it's often 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 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 either. 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. It's obvious VMware is pouring some serious development cycles into the underlying VMFork technology—not just for VDI but also for their flagship vSphere product.

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

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

• It would be best if you had Windows 8 or 8.1 VDis.

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

Previous versions of instant clones had additional limitations, such as incompatibility with static IPs and IPv6 and the inability to delay image updates. Note that 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 there has not been an official End-of-Support announcement for now.

Until then, I'd suggest preparing for future migration with any of the articles referenced above or with some supplemental Horizon 7 training courses for those running linked clones. I hope this article makes your selection process or migration project easier.

Best of luck to you!