Tag Archives: machine creation services

PVS vs MCS – Part 2: Scalability

This is part of a series comparing Provisioning Services and Machine Creation Services

In Part 1 of the PVS vs MCS debate, we saw

  • Provisioning Services bridges the gap between the physical and virtual world
  • Machine Creation Services bridges the gap between the on-premises and cloud world

Let’s continue digging into the PVS vs MCS debate and focus on scalability. Scalability plays a big role in the solution. If one solution only scales to 500 users, it would be a bad idea to select that option for a deployment of 5,000 users.

It seems like more people question the ability for Machine Creation Services to scale than they do Provisioning Services. When Machine Creation Services was initially released, many believed it was only for small deployments of around 500.

So, let’s look at how these two technologies work, which will give us some insight into their scalability potential.

Provisioning Services

Provisioning Services utilizes network streaming. A master image is contained within a single file. Each Provisioning Services server accesses the read-only file, and streams portions of the file to the target devices (FYI booting Windows 10 to the logon screen only requires 250MB of streamed data!).

PVS architectureWhat will bottleneck? Your Provisioning Services server’s NIC.

If you need more scalability, you can increase the NIC speed, add more NICs, add more servers or do a combination.

Machine Creation Services

Machine Creation Services, on the other hand, is not based on a stand-alone server install like Provisioning Services.  The Machine Creation Services functionality, contained within the XenApp and XenDesktop controller, is based on interacting with the hypervisor storage (local and shared). As virtual machines are created and updated, the Machine Creation Services commands are sent to the virtualization hosts.

MCS architectureSo, what will bottleneck first? Your storage.

Each storage cluster can only support so many virtual machines before it cannot handle the incoming requests.  If you need to add more scalability, you need to create additional storage clusters.

Comparing the Two

Both solutions can scale, as long as you add more storage clusters or more servers. But one thing you should keep in mind is that the user experience, or how well the target device performs, is based on different factors:

  • Provisioning Services links user experience to the stability and performance of your network
  • Machine Creation Services links user experience to the stability and performance of your storage

But in terms of scalability, where does that leave us in the PVS vs MCS debate?  Even

MCS vs PVS table

Daniel (Follow on Twitter @djfeller)
XenApp Advanced Concept Guide
XenApp Best Practices
XenApp Videos


PVS vs MCS – Part 1: Resource Delivery Options

This is part of a series comparing Provisioning Services and Machine Creation Services

Five years ago, Citrix released Machine Creation Services.  As a way to help admins decide between Provisioning Services and Machine Creation Services, I created a decision tree, breaking the decision across multiple requirements.

A lot has changed.

Provisioning Services changed.

Machine Creation Services changed.

You know what didn’t change?  Homer, Marge, Bart, Lisa and Maggie Simpson.

You know what else hasn’t changed? The decision tree.  It is old. It is outdated. It is no longer useful.

So my recommendation to you: STOP USING IT!

I want to look at the PVS vs MCS debate again based on the current technology.

I first want to look at the type of resources each platform can deliver.

Both imaging platforms are able to deliver virtual RDS and VDI workloads to XenServer, Hyper-V and vSphere.  The difference between the two lies in the ability to support physical and cloud-hosted workloads.

Provisioning Services, because it relies on network streaming of the master image, is able to deliver the image to virtual and physical endpoints. Imagine if you were in a school computer lab where every 45 minutes the class changed and the endpoint had to run an entirely new suite of software.  With Provisioning Services, we can quickly re-provision physical endpoints with the speed of a reboot.

Machine Creation Services, on the other hand, requires virtualization.  It communicates with the underlying hypervisor and deploys new virtual machines based off of a master image.  Not only does this approach allow one to run on XenServer, Hyper-V and vSphere, but it also allows Machine Creation Services to deploy virtual machines to the Microsoft Azure and Amazon AWS clouds.

If I put this into a simple to understand table, we would get the following:


Provisioning Services bridges the gap between the physical and virtual world.

Machine Creation Services bridges the gap between the on-premises and cloud world.

But of course, the similarities/differences are far greater than what type of resources each method delivers.  And we will get into more in future blogs.

Daniel (Follow on Twitter @djfeller)
XenApp Advanced Concept Guide
XenApp Best Practices
XenApp Videos

Migrate from MCS to PVS

When installing XenDesktop 5, I bet many people were interested in using Machine Creation Services. And why not? It is easy to setup and configure because there is nothing to setup and configure. What could be easier? However, as many of you start to grow your desktop virtualization implementations to include more users, more desktops and more scenarios, you might realize that MCS is no longer able to meet all of your demands. What if you want to do Hosted Shared Desktops or Streamed VHD desktops? No MCS allowed.

If you want single image management, you are going with Provisioning Services. And if you start using PVS for these new use cases, will you also go back and update your other pooled VDI desktop users to also use PVS? Probably. It will make the operational aspect easier with only being required to support a single provisioning solution. Of course the big issue with moving from MCS to PVS is how to migrate your images.

Chances are, you spent a lot of time installing, configuring, and optimizing the base desktop image to align with your business. Do you really want to start over and create a new image for PVS? No way. Well, luckily, it isn’t too difficult to migrate images from MCS to PVS. A new Implementation Guide has just been added to the XenDesktop Design Handbook that provides the steps required to migrate images. Now you don’t have to figure this out on your own, just follow the steps. Take a look at the latest: Implementation Guide: Migrating from MCS to PVS.

Daniel – Lead Architect
XenDesktop Design Handbook

PVS or MCS – What’s Your Decision Going to Be

Note: This blog is in reference to Citrix XenDesktop 5.0 ONLY.

Note: The following link contains the  latest discussion between PVS and MCS (https://virtualfeller.com/2016/05/17/pvs-vs-mcs-part-1-resource-delivery-options/)

The decision between using Provisioning Services or Machine Creation Services is based on many things, with a few being discussed previously:

  1. Big Picture
  2. Operations
  3. Resource Requirements

Let’s say you’ve gone through these discussions and are still trying to determine what approach you should take. Personally, I like to use decision trees, like the following:

By answering these questions, you will get a better idea of what is most appropriate:

  1. Hosted VDI Desktops Only: Larger enterprise environments are often more complex, in terms of end user requirements. The complex user requirements cannot be completely met with Hosted VDI desktops, which require the organization to expand into different options. Using Provisioning Services for these architectures is recommended due to the ability to deliver images more than Hosted VDI desktops.
  2. Dedicated VDI Desktops: If there is a user requirement for dedicated desktops, there is an increased recommendation to use Machine Creation Services or to use installed images.
  3. Large Boot/Logon Storms: Boot and logon storms create massive IO activity on the storage infrastructure, requiring greater levels of IOPS. For larger deployments with a large boot/logon storm, Provisioning Services is recommended due to IOPS savings.
  4. Blade PCs: Certain users require the performance of a Blade PC, while still secure within the data center. Because Blade PCs are standalone hardware devices, Machine Creation Services cannot be used.
  5. SAN: Provisioning Services has the flexibility to work with and without a SAN infrastructure. However, Machine Creation Services becomes more challenging without a shared storage infrastructure, like a SAN. If a shared storage solution is not in scope or is too costly for the environment, Provisioning Services is a better option.
  6. Change Control Processes: Maintaining Provisioning Services desktop images requires proper processes depending on the type of update required (hotfix versus network driver update). Smaller environments will most likely not have processes in place. Maintaining a Machine Creation Services image is often seen as easier.

What did you come up with? Surprised? Or is it what you expected? If you want the full breakdown on deciding between the two options, then please refer to the recently released version of the “Planning Guide: Desktop Image Delivery” which was recently added to the XenDesktop Design Handbook.

If you are new to the handbook, then I suggest you read about it from Thomas’s blog discussing how to get the handbook for offline use.

Daniel – Lead Architect
XenDesktop Design Handbook

PVS or MCS – We Talking About IOPS Again

Deciding between PVS and MCS is a tough decision for many organizations. Although MCS is limited in that it can only do virtual machines, it does appear to be easier to setup than PVS. In fact, MCS just works while PVS requires another server and configuration of bootstrap processes like TFTP/PXE. So it sounds like we should be using MCS for everything. Right? Not so fast. We need to look at the resource requirements, beyond servers, as this might negate the benefit of easier setup/configuration.

If you’ve gone through the other two discussions so far, we focused on the Big Picture of your environment and the operational model. This time, we are focusing on resource requirements.

First, we know that using PVS will require, at least, 2 additional servers (remember I’m including fault tolerance). MCS doesn’t require any extra hardware besides the hypervisor. Now let’s look at storage requirements, and with storage I’m talking about IOPS, our favorite topic.

If you look at PVS, we do all reads from one location and do all of our writes on another location. Because of this, we can optimize the systems. We know that on the PVS server, we allocate enough RAM so the reads happen in RAM and not disk, thus greatly reducing read IOPS.

MCS is different. The reads and writes happen on the same storage. This is a big deal. Look at the graph below.

We know that during desktop startup, we have a huge amount of read IOPS, during logon, it is evenly split, and during the steady state (working), the ratio moves towards writes. Most people are concerned with the boot and logon storms. Because these are more read intensive, you would think that PVS would be the better option for large boot/logon storms as we cache the vDisk in PVS RAM. This line of thinking is correct.

Now before people say, “Hey, my SAN can cache”. You are correct. Of course there are SAN caching solutions, but these cost money. With PVS, it is just part of the Windows operating system. Because of this, we can see a MCS implementation generating more IOPS than a PVS implementation. How much more? I’ve seen as much as 1.5X more IOPS. For deployments with 50 desktops, this might not be a big deal, but what if you are talking about 20,000 desktops?

Some might be thinking about using XenServer IntelliCache to bring these more inline. This has a potential to help lower MCS IOPS requirements, but the products aren’t integrated yet, so I’ve got no data points to share.

But regardless, you need to take the resource requirements into consideration before making your PVS/MCS decision.

Daniel – Lead Architect
XenDesktop Design Handbook

PVS or MCS – Operations Is Important

As we continue to decide between using Provisioning Services or Machine Creation Services in an environment, we need to go beyond the Big Picture factor explained in a previous blog. The second thing we should look at is the operational aspect of the solution. Operational models are rather boring. Who cares about supporting the environment? Well, the users will care and so will you.

First, both models require you to have an operational model in place so you can maintain the base desktop images. We all know Windows 7 Service Pack 1 is coming. How will you update your virtual desktops? This is what the operational model should define.

With Machine Creation Services, the update model is fairly easy. You start your master VM. You install the updates. You shut down. And you use Desktop Studio to push the updates out to all of your pooled desktops.

Provisioning Services is a little different. With PVS you will want to make a copy of the vDisk image. You need to put it into Private Image mode. You need to boot and install the updates. Turn it back into standard image mode, and then run the update command within the console. It doesn’t sound too daunting and it really isn’t. The challenge comes into play when you have updates that impact the connectivity to the Provisioning Services server.

Think about what happens for a moment. You need to update your image. The update impacts the network connection, disabling it for a moment before enabling it again. This is really no big deal unless you NEED the network to continue processing desktop operations. With a PVS streamed desktop, if the network fails, the desktop pauses until the network is restored. If the update disables the network, the desktop pauses. The update will NEVER continue because the desktop is paused.

These types of updates can be done with Provisioning Services, but it requires the team to follow proper processes to prevent issues. Just another consideration to take into account when deciding between PVS and MCS. Stay tuned for more.

Daniel – Lead Architect
XenDesktop Design Handbook

Provisioning Services or Machine Creation Services… Big Picture Matters

Note: this is the first part in a multi-part discussion on PVS and MCS

Since XenDesktop 5 came out, one of the biggest questions flying around is, “Should I use Provisioning Services (PVS) or Machine Creation Services (MCS)?” Both options work and both options provide single image management, but what is the right answer?  Is it shocking that this question is the wrong question to ask?

What you should be asking is “What is my desktop virtualization solution going to look like?” Are we only doing Hosted VDI desktops? Do we need Local VMs? Are Hosted Shared Desktops in the mix? (Note: look at the Citrix FlexCast site for a description of each option). Each organization’s desktop transformation roadmap plays an important role in picking the right option. The following diagram was taken from the XenDesktop 5 Reference Architecture, which can be found in the XenDesktop Design Handbook.

One thing you should be able to see is that if you select Machine Creation Services, you can only do the Hosted VDI desktop model on a hypervisor (XenServer, Hyper-V or vSphere) in the data center ONLY. That means no Blade PCs. It means no Hosted Shared Desktops. It means no streamed VHDs. If this is your roadmap, then Machine Creation Services is still a viable option, but the decision cannot be made yet. You still need to look at a few other considerations like SAN requirements, storm impacts, imaging team expertise, etc. before you can make a proper decision, which will be discussed in future blogs.

But what if your design calls for some of these other FlexCast options? Then Provisioning Services will definitely play a major role. However, there still might be a need for a mixed imaging solution based on a few other decision factors. For example, what if you need a desktop where users have complete control of the desktop to install applications or make operating system-level changes that are not captured in profile management tools? I can still do Existing, Physical, Dedicated and Streamed desktops. However, would you use PVS for this (streamed desktops)? It does work, but you probably won’t go with this option. In my experience, using a private desktop model with Provisioning Services is not efficient. It requires complete copies of the base image, configured for private (read/write) mode. You still have to manage these images in a 1:1 fashion (or use an enterprise desktop management tool). You are essentially adding too many layers where other options might be a better fit.

Why not use an Existing, Physical or Dedicated desktop, which relies on either installed images or MCS? If I go with installed images, I need to either install them one-by-one or use cloning solutions like SysPrep. If I use MCS, unique identities are built into the solution. MCS makes the deployment easier than the Existing or Physical desktop model, but they both work. What does this all mean? If you use multiple FlexCast options with private desktops, you will end up using [PVS + (MCS or Installed)]

You don’t want to focus on which technology to use, you want to focus on the overall architecture, which will help guide your decision. But the decision is based on more than the big picture. You need to stay tuned for more on this topic as this isn’t the end yet. We still need to dive deeper into the Hosted VDI Desktop model only scenario to align our business requirements with the appropriate solution.

Daniel – Lead Architect
XenDesktop Design Handbook