Here is why your Horizon View deployment is not performing to it’s max!

In Horizon View 5.1, VMware introduced a feature called PhoneHome. PhoneHome is an opt-In option for anonymous usage statistics collection. All data is anonymized and untraceable, and phonehome will collect information on versions, features used, system architecture choices and deployment scale. This information is used by VMware to provide better support and enhance to the most popular features. In addition to that VMware can use this data collection to better align research and development priorities to match the way customer are actually using Horizon View.

Screen Shot 2013-12-16 at 12.15.48 PM


One of the things that came out of the reports provided by PhoneHome is that for all deployments with Horizon View 5.1 or higher that are actively sharing information with VMware, only ~27% have the View Storage Accelerator (aka Content Based Read Cache) feature enabled.

Content Based Read Cache is in my opinion one of the most impressive features in Horizon View and vSphere Platform, allowing Administrators to drastically cut-down on read IO operations, offloading the storage infrastructure and providing greater end-user experience.

Screen Shot 2013-12-16 at 12.48.29 PM

CBRC  helps to address some of the performance bottlenecks and the increase of storage cost for VDI. CBRC is a 100% host-based RAM-Based caching solution that help to reduce read IOs issued to the storage subsystem and thus improves scalability of the storage subsystem while being completely transparent to the guest OS. VMware tests have identified a boot storm reduction of approximately 80% on peaks IOPS, ~45% on average IOPS, ~65% on peak throughput and ~25% on average throughput.

Screen Shot 2013-12-16 at 1.12.01 PM

Surely there are other factors that will influence on the overall end-user experience, like write IO operations and CPU consumption, but CBRC is free and it’s there to be used. PLEASE, read more about CBRC and ENABLE IT in your environment. Your users will thank you! 
Here is a list of CBRC articles:

This article was first published by Andre Leibovici (@andreleibovici) at


1 ping

Skip to comment form

    • Lee on 12/16/2013 at 6:18 pm

    While I love the CBRC technology, I have found it too immature when using desktops I a manual pool. We use persistent virtual desktops with one to one user mapping, so there is no linked clone / master to generate the CBRC. The generate script, which runs every 7 days by default, requires the. VM. Be powered off, and keeps the VM locked while generating. This is a deal breaker for us, and one I have been watching through 5.1 updates and now 5.5, but I don’t believe this has been fixed. What puzzles me, is the technology to run it powered on should be very similar to CBT (change block tracking) feature implemented in 5.0 (?) and used by nearly every backup vendor.

    • Arnold on 12/17/2013 at 2:06 am

    Lee has nailed it with his comments. Downtime is a deal breaker

  1. Lee and Arnold, while I understand that CBRC is not great for full clones and manual pools, it is fantastic for linked clones. I would recommend you testing a linked clones pool with CBRC. The replica data set is stored in RAM, providing sub-millisecond latency.

    • forbsy on 12/18/2013 at 3:15 pm

    The digest file takes waaaay too long to create. It pushes linked clone creation and recompose tasks to unacceptable times. If the digest file creation time was much less, I’d consider CBRC. Also 2GB read cache per host isn’t much. Especially when we can now get 150 desktops/server in some situations.

  2. Forbsy, in the new version you can do rolling recompose updates to pools (basically tell the pool to not remove all available desktops until enough new ones are ready).

    This way you can do recomposes in the middle of the day (Unless you undersized your storage).

  3. Lee, if your doing persistent desktops with FULL clones, I’d argue your not really taking advantage of view properly, or your leveraging your array’s cloning system and then the array should be deduping/caching out hot blocks anyways.

  4. I like the new feature of VMware of PhoneHome in Horizon View 5.1. And @Nicholson i am fully agree with you that we can rolling recompose updates to pools in the latest version.

  1. […] ???: Here is why your Horizon View deployment is not performing to it’s max! » […]

Comments have been disabled.