VDI: A Guide to Citrix Provisioning Technologies
One of the more challenging subjects to grasp in the VDI world is that of the underlying provisioning technologies that enable scaling. Whether you’ve narrowed down your VDI options to a single vendor or still in the midst of your decision making process, obtaining a deeper understanding of the provisioning technologies available to you will open doors for your architecting and design efforts.
A provisioning technology can loosely be defined as a mechanism which enables administrators to create replicated copies of a provided machine’s state in a precise and efficient manner. Typically, the process involves configuring a machine with a desired setup, creating a reference point, and having new/downstream machines refer back for their desired running state. At scale, this becomes a driving factor for VDI success as a single VDI administrator can manage thousands of machines with guaranteed compliance.
What are Your Citrix Provisioning Options?
Citrix’s provisioning technologies have come a long way through the years. Being the first to market in this space, it’s quite understandable that the quantity of time Citrix has inhabited this space has produced an evolution of radically varying approaches. At the time of this writing, the current release of Citrix Virtual Apps and Desktops is the 2003 release. The CVAD 2003 release supports the following types of Machine Catalogs:
- Citrix Provisioning (formerly Provisioning Services (PVS))
- Machine Creation Services (MCS)
- App Layering (formerly Unidesk)
Each of these solutions has their own merit, however, let us explore the current status of each and illuminate any caveats that may or may not still exist.
What is Citrix Manual Provisioning?
Manual provisioning refers to the more traditional approach of building virtual machines (VMs) one-at-a-time as individual, independent VMs. This is usually the easiest solution to get off the ground. However, it serves as the least scalable due to its inherent requirement to treat maintenance and troubleshooting tasks as isolated incidents. This option is normally the least desirable.
4 Citrix Provisioning (PVS) Options
PVS is Citrix’s long-standing provisioning technology. With this comes years of development and a proven reputation for scalability. Understanding PVS requires learning terminology for its various components. Below you’ll see a chart summarizing their definitions, which should ease the conversation along.
|PVS Terminology||Reference||Layman’s Explanation|
|Target Device||Machine||The downstream machine to be booted…typically referenced by MAC address.|
|Device Collection||Grouping of Machines||How you group downstream machines for ease of management and configuration.|
|vDisk||Bootable Base Image||Better referred to as the golden image machines will boot from.|
|Store||Disk repository||Where your vDisks are located — physical or virtually.|
Like any other provisioning technology PVS’s goal is to provide a scaling relationship whereby downstream machines can run from a single upstream image. PVS accomplishes this by streaming the needed data across the wire network bit by bit as each piece of data is needed. The process can be described this way:
- Target devices are PXE booted over the network and acquire their boot configuration file from a DHCP server (separate from the Citrix PVS install).
- Target devices then contact the PVS server identified.
- The PVS server looks up the associated target device (referenced by its MAC address) and finds the associated vDisk to be presented. A validity check is performed to verify the availability of the store where vDisk resides
- The PVS server begins streaming the necessary bits, on demand, to the target device.
One other important factor to consider is that operating systems require a location for their writes to be stored. For this, PVS offers multiple caching options whereby writes can be either cached to the target device’s memory or to a local storage disk.
Using this method, PVS is able to provide replicas from base images in the time it takes a machine to boot from the network. Similarly, updates can be pushed to target devices with a simple reboot rather than having pending installs. For these reasons, PVS has won over the hearts of many Citrix gurus and for some is the de facto provisioning standard.
Citrix Machine Creation Services (MCS)
MCS is the “new kid on the block” in the Citrix world — touting a storage-based copying solution that allows the cloning of one VM to thousands of downstream duplications. For this solution, we’ll certainly need a picture to help illustrate how it works.
This picture illustrates a few things. First let’s start with how the MCS master image is replicated. The process begins by creating a VM in your hypervisor; setting it up as desired with your required operating system (OS), applications, and their necessary configurations. Once the image is in the desired state, a snapshot is taken to capture the point-in-time configuration. MCS then takes a combination of the base image and snapshot and rolls them into a singular master image disk. A copy of the master image is then copied to each storage volume configured in your hosting diagram. Now we’re ready for MCS machines to be created.
MCS machines are composed of three disks: (1) a read-only master image; (2) an identity disk; (3) and a differencing disk. Access to the read-only master image, mentioned above, is shared amongst other MCS devices residing on the same storage volume. The identity disk’s role is inherent in its name, in that it maintains the machine’s unique identity by persisting the computer name and storing the computer’s AD account password. The differencing disk stores any changes written throughout the machine’s usage.
It’s important to note that upon an MCS machine’s reboot, the differencing disk is cleared — effectively, reverting the MCS machine back to its master image configuration. A folder with the name of the MCS machine is created in the storage volume where the MCS machine resides. This folder contains the identity and differencing disks necessary for the machine’s operation.
By having MCS machines utilize the same read-only copy of the master-image, MCS is able to greatly reduce the storage footprint necessary for VDIs.
Citrix App Layering: A Step Beyond MCS
Formerly known as Unidesk, Citrix App Layering expands upon the MCS concept of using shareable read-only disks for downstream consumption by providing a bit more granularity. With App Layering, three types of disks exist (known as layers): (1) OS layers, (2) app layers, and (3) user layers. The picture below depicts just how these pieces fit together.
OS layers provide the base operating system upon which subsequent app layers and machines will be built. App layers are built upon the OS layers and are independently packaged components that can be hot-swapped onto machines. Lastly, there are user layers. User layers perform two critical functions: (a) capturing the users’ profile/personalization settings; (b) capture any applications installed by the user. In essence, user layers provide a persistent experience in a non-persistent VDI setup.
Collectively, with the help of some fancy things called filter drivers, these layers are combined together to present a consolidated C: drive with all the apps and settings defined in the layers. App layering even allows for app dependencies to be mapped, so prerequisite apps are loaded prior to consolidation. Citrix’s robust solution documentation is certainly more than we can cover in the span of this article. Feel free to read more on the details of how App Layering handles any conflicts and prerequisites.
The key differentiator with App Layering comes from its ability to provide as near a persistent experience you can provide from a provisioned VDI environment. The customization options granted by independent app layers and a user layer that allows for manual installs is really unmatched in this space.
Citrix Provisioning: Pros and Cons
Now that we have an understanding of what options are available to us, what is the real scoop on these products? Citrix provides a great resource for aiding in this discussion, but those are the hard facts of what each solution supports. I’d like to provide a more behind-the-scenes summary of my own adventures — lessons learned, experiences and long nights — down to a few short sentences on each.
Citrix PVS: Relies Heavily on Network Resources
PVS is a proven solution for rapidly providing scalable machines for consumption. The initial setup and configuration is not overly challenging. However, it will require the cooperation of your networking team to ensure certain configurations. With this being said, PVS relies heavily on network configurations and can become a pain point for Citrix or virtual infrastructure administrators who may have limited control over the network or network changes.
A quick DHCP scope option changed here or spanning tree protocol configuration there and quickly this solution can have the team scratching their head while attempting to reverse engineer the root cause of an outage.
Because of this, unless your team has, at a minimum, full visibility into the network infrastructure, I would recommend thinking twice about PVS as I’ve seen more than my fair share of pointing-matches between virtual infrastructure and network teams. Secondly, another old caveat of PVS was its reliance on a physical server to run the provisioning services. With most modern data centers housing a 10G core this issue is mostly transient, though do ensure your processors can handle the workload and affinity rules are set to avoid the PVS server from migrating.
Citrix MCS: Storage Heavy, But Fast
MCS is the surefire method for quick deployments as it requires no additional infrastructure other than your hypervisor and the base Citrix install. To plan out a proper MCS deployment though you’ll certainly need some discussions with your storage admins. Discussions about the number of volumes to be provisioned, their size, the number of VDIs per volume and overall IOPS expected for each VM. Like how PVS relies heavily on the network, MCS relies heavily on storage.
An early concern with MCS was its inherent elevated IOPS. Luckily, two advancements on this front have caused this to become a null issue for most environments. For one, advancements in flash storage arrays have largely diminished this concern as even most hybrid arrays can now handle the workloads without a blip. Secondly, Citrix stole a trick out of the PVS playbook and gave MCS the added feature of a RAM cache they dubbed MCS Storage I/O Optimization. This greatly reduces the IOPS burden placed on the storage.
Another consideration often brought up is the scale to which MCS is capable of expanding. The long touted number for MCS’s maximum potential is around 2,500 VMs. To be clear, the scale to which MCS can grow is completely dependent upon the underlying infrastructure. And to my lack of knowledge and ability to find anything to the contrary, Citrix has never announced an official hard-limit on MCS’s capabilities. With this being said, it’s no secret that PVS is the proven solution when you get to the level of discussing thousands of VMs.
Citrix App Layering: Separate Install & Management
Seeing how Citrix App Layering was a more recent acquisition in this space, it hasn’t quite fully made its way into the full Citrix stack. It’s worth noting that the App Layering product is a separate install and requires a separate management console. Likewise, when creating a machine catalog you won’t see an option for App Layering and the machines will need to be added under the manual type or published via a layered image through PVS or MCS. The options here get kind of messy as really there’s no wrong way to cut the cake, but that’s also part of the beauty.
App Layering is a robust and diverse product where we’ll likely see some interesting developments in the coming years. With this comes rapid changes and alterations to the product line with fascinating features, of which some will be depreciated in a few years. R.I.P., Personal vDisks. With that being said, App Layering is a space to watch from afar unless you have strict guidelines that require you to provide a near fully persistent experience while maintaining a manageable VDI environment.
While there are many opinions on this matter, your business needs will dictate what the best fit is for you. As always, follow best practices and read every article out there with a grain of salt (including this one) and perform a POC with the mentality of “trust, but verify.” I hope you found some wisdom in this article and be sure to check CBT Nuggets for resources on Citrix’s latest advancements in this space.