The last couple of days I had some great discussions with co-workers and some (VMware minded) guys on Twitter. The subject? The complexity of setting up Citrix XenDesktop, most of them refer to some demo they saw or things they’ve read on blogs/twitter etc while they know View is pretty easy to configure. But the thing is that those demo’s are mostly from a VMware View point of view and in the comparissons I’ve seen, Citrix PVS is used instead of Citrix MCS.
So what is Citrix Provisioning Services
Citrix PVS is a more complex way to deliver an OS to a VM as showed on the following diagram:
What’s important here is that you should realize that Citrix PVS is a independent solution from XenDesktop. You don’t have to use XenDesktop in order to leverage PVS and vice verse.
From the eDocs pages:
Most enterprises struggle to keep up with the proliferation and management of computers in their environment. Each computer, whether it is a desktop PC, a server in a data center, or a kiosk-type device, must be managed as an individual entity. The benefits of distributed processing come at the cost of distributed management. It costs time and money to set up, update, support and ultimately decommission each computer. The initial cost of the machine is often dwarfed by operational costs.
Over the years, various software solutions have been offered that are designed to address the operational challenges faced by IT organizations. For example:
Imaging solutions allow backup and duplication of existing machines.
Distribution tools can automate many of the tasks required to install and upgrade software across many computers.
Simplifies the management of the end points by removing most software and processing locally.
Each of these approaches has benefits and limitations. Provisioning Services takes a very different approach by fundamentally changing the relationship between hardware and the software that runs on it. By streaming a single shared disk image rather than copying images to individual machines, Provisioning Services enables organizations to reduce the number of systems that they manage, even as the number of computers continues to grow. This solution simultaneously provides the efficiencies of a centrally managed solution with the benefits of distributed processing.
Provisioning Services Streaming Technology
Provisioning Services streaming technology allows computers to be provisioned and re-provisioned in real-time from a single shared-disk image. In doing so, administrators can completely eliminate the need to manage and patch individual systems. Instead, all image management is done on the master image. The local hard-disk drive of each system may be used for runtime data caching or, in some scenarios, removed from the system entirely, which reduces power usage, system failure rates, and security risks.
Provisioning Services Solution
The Provisioning-Services solution’s infrastructure is based on software-streaming technology. Using Provisioning Services, administrators prepare a device (master target device) for imaging by installing any required software on that device. A vDisk image is then created from the master target device’s hard drive and saved to the network (on a Provisioning Server or storage device).
Once the vDisk is available from the network, the target device no longer needs its local hard drive to operate; it boots directly across the network. The Provisioning Server streams the contents of the vDisk to the target device on demand, in real time. The target device behaves as if it is running from its local drive. Unlike thin-client technology, processing takes place on the target device.
During the conversations it happens quite often that when I mention MCS people don’t really know what MCS is.
So what is Citrix Machine Creation Services
Daniel Feller wrote a great blog on what MCS is:
Machine Creation Services (MCS) is one option for desktop image delivery. It simply uses the hypervisor APIs (XenServer, Hyper-V, and vSphere) to create, start, stop, and delete virtual machines. Let’s say we want to create a catalog of desktops with MCS, you can pick either:
- Pooled-Random: Desktops are assigned randomly. When they logoff, the desktop is free for another user. When rebooted, any changes made are destroyed.
- Pooled-Static: Desktops are permanently assigned to a single user. When a user logs off, only that user can use the desktop, regardless if the desktop is rebooted. During reboots, any changes made are destroyed.
- Dedicated: Desktops are permanently assigned to a single user. When a user logs off, only that user can use the desktop, regardless if the desktop is rebooted. During reboots, any changes made will persist across subsequent startups.
The creation process is as follows regardless if you are doing pooled-static, pooled-random or dedicated:
- Manual Step: First, have your master virtual machine created. This means you need to define the VM (vCPU, RAM, Disk space), install the OS, install the apps and make any configurations you want to be part of your user’s desktops. If you are thin provisioning the disk, you only use the amount needed up to your maximum amount define.
- Manual Step: Within Desktop Studio, you create a catalog for a pooled desktop and you have to select the master virtual machine you want to base other VMs on. This is the one you installed and configured with the OS and applications.
- Automatic Step: MCS creates a snapshot (thin) of the master VM unless you selected a snapshot, which will not create another snapshot. This uses minimal space
- Automatic Step: MCS creates a full copy of the point in time snapshot and places this on each storage repository defined in the host connection. This will utilize the amount of space used for your complete image.
- Automatic Step: MCS adds these desktops into Active Directory. This step creates the unique AD identities to be used later in the process
- Automatic Step: MCS creates the number of VMs specified in the create catalog wizard with two disks defined for each VM. However, in addition to the 2 disks for each VM, a master will also be be stored in the same storage repository. If you have multiple storage repositories defined, then each one will get the following types of disks
- The full snapshot, which is read-only and shared across the VMs just created. Each storage repository will get one. This is the same disk identified in step 4.
- A unique identity disk (16MB) used to provide each VM with a unique identity. Functionality within the XenDesktop Controllers creates the identity disks. Each VM gets an identity disk.
- A unique difference disk used to store any writes made to the VM. The disk is thin provisioned (if supported by the storage) and will increase to the maximum size of the base VM if required. Each VM gets a difference disk.
The differences appear when the desktops are put into production:
Pooled-Static Pooled-Random Dedicated First logon User-to-desktop association stored permanently in the SQL Database User-to-desktop association stored temporarily in the SQL Database User-to-desktop association stored permanently in the SQL Database Logout User-to-desktop association remains User-to-desktop association removed User-to-desktop association remains Subsequent logons XenDesktop Controller directs the user to the permanent desktop association XenDesktop Controller picks any available desktop and temporarily stores the association in SQL Database XenDesktop Controller directs the user to the permanent desktop association Reboot Differencing disk disconnects and a new disk is created. Old differencing disk deleted after startup complete Differencing disk disconnects and a new disk is created. Old differencing disk deleted after startup complete Differencing disk is permanent
So if you want to focus on the differences in complexity of both View and XenDesktop remember that MCS is available and pretty easy to configure and more comparable to VMware View with the Composer. While PVS is more scalable and suitable for deployment of different OS’s with different purposes. Those are the key decision making points when one has to choose between PVS/MCS and keep in mind that it’s relatively easy to migrate from MCS to PVS as stated in this blog there’s a well written implementation guide here.
Latest posts by Kees Baggerman (see all)
- Nutanix AHV and Citrix MCS: Adding a persistent disk via Powershell – v2 - November 19, 2019
- Recovering a Protection Domain snapshot to a VM - September 13, 2019
- Checking power settings on VMs using powershell - September 11, 2019
- Updated: VM Reporting Script for Nutanix with Powershell - July 3, 2019
- Updated (again!): VM Reporting Script for Nutanix AHV/vSphere with Powershell - June 17, 2019
Can MCS leverage local SR’s? If so, how does MCS differ fdom VDI-IN-A-BOX?
MCS (the Desktop Delivery Controller) leverages the built-in capability of the hypervisor to create clones and snapshots so yes it can be used on local SR’s as long as the hypervisor can ;-). Where it differs from VDI-in-a-box is limited at the number of desktops that can be hosted while MCS is tested way above the number of desktops that can be delivered via VDI-in-a-box.
[…] My Virtual VisionCitrix: MCS, Citrix's best kept secret for server virt guys? – My Virtual Vision […]
Thank you for posting this article.
It’s interesting to hear that the people with whom you’ve discussed this topic think setting up XenDesktop is complex.
Over the past 18 months or so, we’ve worked with hundreds of organizations around the world who have deployed XenDesktop and they’ve always remarked how easy it was to set up. Even more interesting was that every single one of these customers used Provisioning Services. And their decision to use PVS wasn’t based solely on the fact that they had different OS images or that they wanted to ensure they could scale out their virtual desktop infrastructures to thousands of desktops quickly and seamlessly when necessary. Their decision was also rooted in their ability to set up a XenDesktop POC quickly and easily and then move from POC to production in minimal time and with minimal effort using the same servers and storage they used during their POC.
If it wasn’t already easy enough, PVS 5.6 SP1 and above includes a XenDesktop Setup Wizard, which allows customers to create hundreds of virtual machines that will host virtual desktops within minutes.
I’ve seen XenDesktop infrastructures get set up in as little as one day thanks to PVS, the XenDesktop Setup Wizard and the direct integration with the Desktop Delivery Controller.
Of course, having flexible, scalable, highly available and easy to manage shared storage that greatly simplifies image management and maintenance, reduces storage cost and enables PVS HA for image high availability, as well as provides database HA without all the complexity and cost associated with SQL Clustering or SQL Mirroring, gave these organizations all the more reason to use PVS in their XenDesktop deployments.
Here’s a quick link that explains why hundreds of Citrix customers have found XenDesktop extremely easy to implement and why the ROI on their investment in XenDesktop has not only been rapid, it’s been much greater than they ever imagined!
The secret sauce is the identity disk that Citrix got from Ardence and is incorporated in MCS too…no need to run quickprep or sysprep when new vm’s are created. Makes deployment go really fast 🙂
[…] Is Horizon just one console? I was reading an article last week on the VMware pages which states that VMware Horizon needs 4/5 appliances and desktop pools can’t be managed from Horizon Workspace console so you still need a VMware View console for management of your desktop pools. Btw, for all those not familiar with MCS/PVS: MCS, Citrix’s best kept secret for server virt guys. […]
Correct me if I am wrong, Can MCS deploy Hosted Shared Desktops based on Win 2012? Any gotchas that I need to bear in mind?
Yes, XD7 can deploy WS2012 shared desktops via MCS. I’ve got it running in the lab including WS2008R2, Win7, Win8 and WS2012.