VMware vSphere CBRC removes the need for Citrix Provisioning Services

I know this will be a sensitive topic among some Citrix folks…but I personally dislike the product (Citrix Provisioning Services). I dislike it because it’s not the most straightforward product, it’s had its share of challenges (E1000, vmxnet3 for example), and even with n+1 Provisioning Servers I’ve still seen bugs that crash the stream service, targets fail over to the other node, then promptly crash that stream service. There are some scenarios like streamed OS over the LAN for lab, campus, education environments where I can overlook any shortcoming because the product frankly is the best solution on the market for these types of environments…game changer for sure, no question. But in other environments where we use it to manage large XenApp farms and deploy hosted virtual desktops I think we’re starting to see advancements in the hypervisor that will reduce the need for Provisioning Services, that’s not a bad thing, just other technology catching up.

I’ve talked about the VMware vSphere Content-Based Read Cache (CBRC) in a previous post, namely how to enable it on your Machine Creation Services (MCS) provisioned virtual desktops. For those of you who are not aware, CBRC was introduced in VMware vSphere 5 to provide a method for providing a memory based read cache for frequently accessed portions of a vmdk virtual hard disk.  Text from the VMware blogs states:

When enabled for specific VMs, the host hypervisor scans the storage disk blocks to generate digests of the block contents. When these blocks are read into the hypervisor, they are cached in the host based CBRC. Subsequent reads of blocks with the same digest will be served from the in-memory cache directly.  This significantly improves the desktop performance, especially during boot storms or anti-virus scanning storms when a large number of blocks with identical contents are read. 

Now first a few caveats on my title of this post. Today you need and use Provisioning Services for the following:

  • Non-persistent image delivery for Citrix XenApp worker nodes, this is the best way to successfully manage large deployments of Citrix XenApp as you have single image management and non-persistent user nodes, it’s nearly bulletproof and provides a significantly reduced hardware cost model when compared to VDI/hosted virtual desktops
  • Image delivery for Windows XP/7 virtual desktops where you want to use the read cache of Provisioning Services and the Windows operating system to increase scalability and reduce read IOPs. Additionally the single image management, rather than using replica images on each datastore does reduce overall storage requirements.
  • Streamed OS delivery to physical PC’s over the LAN (this is the only future I see for PVS)

The major advantage to Citrix Provisioning Services (PVS) vs Machine Creation Services (MCS) is that PVS is a giant read cache for all of the images it serves up. While there is some storage savings too, it’s usually not a significant enough amount to drastically impact a project cost or complexity.

Now imagine a future world where Citrix can take advantage of the Content-Based Read Cache (CBRC) for Windows XP/7 virtual desktop delivery using MCS. Instead of your Citrix Provisioning Server/OS serving the read requests from memory the VMware vSphere hypervisor does this.

Imagine in that same future world what Citrix has already hinted publicly about (at Synergy) which is the combining of Citrix XenApp IMA architecture into the current XenDesktop FMA architecture, a world where provisioning XenApp worker nodes via MCS might be possible. Again, these images could then take advantage of the hypervisor read cache.

So I ask you…how long do you think Provisioning Services is going to matter for XenApp and XenDesktop hosted delivery? Now all we need is for Citrix to work with VMware to support CBRC with MCS provisioning…and while they are at it adding support for CSV cache on Windows 2012 would be nice too.

Glad to hear your comments on this…I wrote this rather quickly tonight and I’m sure I’ve overlooked an argument or two 🙂

11 thoughts on “VMware vSphere CBRC removes the need for Citrix Provisioning Services

  1. I agree and posted on this a while back as well:
    http://speakvirtual.com/2011/07/29/citrix-provisioning-server-the-end-is-near/

    There needs to be some improvements in MCS before it overtakes PVS though, IOPS isn’t its only benefit. First, MCS needs to make it so the base image only needs to be stored on one LUN, similar to how VMware View does it. Copying the base image to every LUN you are provisioning VMs on is too time and space consuming. Particularly with large deployments that often have several base images, this just isn’t realistic. Second, the process to provision new VMs, particularly when you get to the thousands of VMs is just to time consuming. Improvements need to be made so that provisioning or updating machines is close to as fast as PVS. Third, there are certain features of the hypervisor you just can’t use with MCS or View. Things like Storage vMotion/Storage DRS. Even in a VDI environment, I find these features very valuable. Once those changes are made though, MCS should and will suppland PVS. I’d give it two more years.

    -Nick

    1. VMware View and Citrix XenDesktop using Machine Creation Services all create a replica disk image per datastore, it is from this replica that linked clones are created. VAAI helps us in a few ways with this, first our LUNs are now much larger therefore we have less datastores, less replicas that have to be made and therefore less wasted space…plus VAAI could also improve the clone performance, provided the call to create replica is using some clone command that vSphere would issue a VAAI call for.

      Agree on the Storage vMotion/Storage DRS, especially for persistent VM’s, although I think that issue might also exist with PVS as it also has vSphere dependencies.

      1. Dan, as of View 4.5 you have the ability to specify a single LUN to store your replica disks. You can then specify separate LUNs for all your linked clones. MCS does not currently have this feature. I agree that VAAI lessens the impact here, but at large scale, you will still have several LUNs and MCS is going to copy that replica to every one of them. This is something I’d imagine they are working on resolving. As far as storage DRS/storage vMotion is concerned, there’s nothing preventing PVS from using it that I’m aware of. I’ve used it myself and the only place Citrix specifies this as not being supported is in regards to MCS…which makes sense given MCS’s underlying architecture.

  2. Huge potential here, and would provide an awesome blend of the simplicity of MCS with the efficiency of CBRC. I’d think that would have awesome implications for VDI-In-a-Box?

  3. May want to update your article, as it is now obsolete with the introduction of PVS 7.6. Cache to RAM with overflow to disk.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s