First let me state, I highly doubt VMware or Citrix is going to support you if you enable this in your production environment, let’s hope this post changes that.  I’m also quite surprised at how easy it was to enable and use this.

You may not all be aware of this but VMware vSphere 5 introduced a new feature called “Content-Based Read Cache” (CBRC). Here is text from another website explaining it:

Content-Based Read Cache. A content-based reach cache (CBRC) has been delivered for specific use with View (VDI) workloads. With this option configured in ESX, a read cache is constructed in memory optimized for recognizing, handling, and deduplicating VDI client images. The cache is managed from within the View Composer and delivers a significant reduction, as high as 90% by early estimates, in IOPS from each ESX host to the storage platform holding client images. This reduction in IOPS enables large scaling of the number of clients in case multiple I/O storms, typical in large VDI deployments, occur.

If  you’ve read my other posts on about VDI and IOPs you know that I don’t believe that boot storms are a real problem in most production environments and that login storms and write IO in general are the bigger problem we have to deal with for Desktop Virtualization to succeed. However, if we can allocate a small amount of memory (up to 2 GB in this case) on the hypervisor to reduce IO to the storage then of course we’re going to want to do this!  Outside of the boot process any operating system files or applications installed into the gold image would also benefit from this read cache in memory on the host.

So I began pondering the use of this within Citrix XenDesktop and was reading a post on http://www.virtuallyghetto.com/ that outlined quite clearly how to enable this feature. My test was to see if I could get a Citrix XenDesktop Machine Creation Services (MCS) provisioned image to take advantage of the content-based read cache (CBRC).  I was originally stuck on how to run the ConfigureDigest_Task method through VMware vCenter but William set me straight and also updated his post to include more specific instructions on how to configure this. If you try to run the ConfigureDigest_Task against an individual vSphere host that is part of a vSphere cluster you’ll end up getting an error message at the end of the task that says it can’t complete because it is restricted to the server managing it. If you get this go through the vCenter MOB or remove the vSphere host from the cluster, I don’t recommend the latter.

In order to use the Content-Based Read Cache (CBRC) you only have to configure the gold image to be optimized by vSphere CBRC. The configuration to the gold image must be made prior to deploying the gold image into your XenDesktop machine pool. You don’t have to do anything to the MCS provisioned desktops from that gold image, they use linked clone technology and therefore vSphere is able to take advantage of the read cache it has built from the master image, which was then cloned as replica’s on each datastore, that your VM’s are now linked to.

Here is the quick list of steps I went thru, refer to this article on virtuallGhetto for detailed information.

• Create XenDesktop gold image
• Under advanced settings of the ESXi host configure CBRC and cache size you require
• Get the gold image virtual machines MoRef ID and the virtual disk device ID
• Construct the ConfigureDigest_Task method with above information
• Verify the task executes, you’ll also see a new VMDK with the name “digest” configured with the VM
• Create Machine pool
• Look at the CBRC statistics to make sure your VM’s are using the read cache

I can’t thank virtuallyGhetto.com enough for the information they posted, their post was key for me getting this to work. I highly recommend following this blog.

So I did some quick performance comparisons using 15 Windows 7 VM’s (unoptimized) in our lab on a Cisco UCS C200 M1 server, I would have done more but there was only 24GB of RAM in it (anyone want to send me more?).  I allocated 2048MB of memory for the CBRC. Storage for the test was a Nimble Storage CS-240G array using two 1Gb links. As you can see by the graphs in the image below, it’s pretty clear the CBRC worked for the MCS provisioned VM’s.  As to the overall savings in IO it will be dependent on the number of virtual machines that are sharing the gold provisioned image.

This post was not intended to prove savings or justification of a read cache, simply that you can make it work for XenDesktop. However, I believe you also need to regenerate cache by running the digest task occasionally although I’m still short some much needed documentation on why…I have some guesses but nothing concrete.  If anyone has some documentation they’d like to send my way my contact information is on my blog site.

Check out the results…