Anyone who has worked on XenDesktop will have definitely heard the terms: MCS and PVS. You have to choose either MCS or PVS to deploy VDI in an Enterprise environment. This is one of the major concerns for every organization, which they would like to be answered by a Citrix solution architect while working on a desktop virtualization project:
Which delivery technology is better, MCS or PVS?
Now, let's start by learning some basics about these two technologies.
Machine Creation Service (MCS) provides the simplest functionality for the creation and maintenance of desktop catalogs. A step-by-step walkthrough on how to create/configure this feature can be found in the XenDesktop 7.x install guide. You can easily download this guide from http://www.citrix.com.
MCS-based deployment will have the following characteristics:
A master image is prepared from a standard VM with all the customized apps and software that an admin wants in his virtual desktop.
A master image file (
.vmdkor.vhddepending on the supported hypervisors Hyper-V, XenServer, or VMware ESXi) is stored in the central datastores attached to the hypervisor pool.The admin provides custom settings for vCPU, memory, HDD, and many more.
VMs are created as linked clones with at least two disks attached to them; a base OS disk and a personality disk containing the machine-related information.
One difference disk will be attached to the VMs that are used to store and write the information to the VM. The disk used is as thin as provisioned (it needs to be checked for storage compatibility, if it is supported) and the disk size will grow along with your base disk to the maximum if required.
A personal vDisk can also be attached to each VM to store persistent changes for users.
There are four types of resource catalog that MCS offers:
Pooled-Random: This is most commonly used for standard users. Here, the desktops are assigned randomly. When the user logs off, the desktop becomes free and is available for another user. Any changes made to the desktops are undone on reboot.
Pooled-Static: These desktops are for task workers who need the same desktop every time they log on. These desktops are assigned to a single user and on user logoff this desktop is not free for other users. On rebooting, any changes made to these desktops are undone like Pooled-Random.
Dedicated or personal desktops: These desktops are meant to provide persistence to users and are recommended for task workers who need their own set of apps and control on their desktops. These are permanently assigned to a single user. When the user logs off, these desktops are not available in the pool for other users. All the changes made remain intact with subsequent reboots.
XenApp based Shared Desktops: You have been using these desktops since the old MetaFrame Presentation server model. These are the hosted server-based published desktops where the server desktop is made available to the users to be shared with a set of users simultaneously.
The following diagram outlines the basic architecture of MCS:
Provisioning Service (PVS) infrastructure is a result of Citrix acquiring Ardence, which is based out of Virginia, US. Ardence developed a boot program called the Ardence boot program that works on the PXE TFTP technology on which PVS streaming works. If you have worked on PVS previously, you must have heard of the major component ARDBP32.BIN being used for streaming in PVS, it still has the first three initials from Ardence.
PVS is a software streaming technology that Citrix uses to provide on-demand streaming of operating system content in real time from a single shared-disk residing anywhere on the network. Apart from the on-demand streaming, PVS simplifies image management as you don't have to manage images separately. Single-image management simplifies everything and you don't need to purchase any desktop deployment tools to manage this image.
Provisioning Services manages all writes to the vDisks with PVS write cache when using a vDisk in Standard mode (it is often called the read-only mode). You can configure the location of your write cache as follows:
Cache on provisioning server (with or without persistence)
Cache on target device RAM
Cache on target device RAM with overflow to HDD
Cache on target device hard drive (with or without persistence)
One of the most commonly used methods to store a write cache is to store it in the target device hard drive. There is a very good reason to follow this approach as it keeps the write location close to the target device, which actually minimizes the additional load on the PVS servers and also minimizes the load on the network.
Refer to the following diagram for the basic PVS architecture:
PVS architecture
Refer to the following diagram for the basic PVS communication flow:
PVS communication flow
A PVS-based device can have three types of disks attached to it:
The base OS shared disk is placed at the central PVS vDisk store and is streamed on each VM using PXE boot or BDM. You won't find this disk on the VM configuration on hypervisor, as this is streamed to VM either via PXE boot using either TFTP from a vDisk store or using BDM ISO.
Note
Boot device manager (BDM) is a utility that provides an optional method for providing IP and boot information to target devices. With this method, when the target device is booted, it fetches the boot information directly from the boot device. So, the target device would use this information to locate and boot from the required provisioning server.
The write cache disk, unless you have set the write cache on the PVS server or the device RAM.
A personal vDisk.
XenDesktop offers four types of resource catalog with PVS. The first three are the same as the first three resource catalogs that MCS offers, which we covered earlier in this section; that is, Pooled-Random, Pooled-Static, and XenApp-based Shared Desktops. The last one is Remote PC Access, which is a regular Windows desktop that is assigned to a single user which can be accessed locally or remotely.