In the last couple of years any VMware View presentation or blog you saw regarding troubleshooting usually pointed to one thing: storage. We all love to blame the networking people or the storage people (especially if those roles don’t all belong to one person, you!), but this comes down to a bad design of your storage and View environment. Maybe you didn’t have the budget to do what you really wanted, or maybe your View environment grew faster than you planned; either way, it’s going to lead to slower desktops and perhaps user complaints.
VMware is trying to address some of these issues, especially for smaller companies that don’t have tiered storage. Tiered storage implies that you have maybe some SSDs (faster performance), Flash, SATA, and/or SAS (slower performance) in your storage array, not just all SATA for example. The View Storage Accelerator included in View 5.1 (it’s sometimes referred to as Host Caching) addresses the bottleneck that comes from I/O requests from a virtual machine to a host. View Storage Accelerator actually reduces the amount of read I/O requests; this can lead to better performance during boot storms, better performance when users load applications like Microsoft Outlook and Adobe Reader, and many other advantages. For a full list of advantages and some limitations, read VMware’s View Storage Accelerator white paper (PDF).
One limitation is the View Storage Accelerator does require more storage space for a digest file that gets created for each VMDK (-digest.vmdk) — it averages about 100MB per each 20 GB Windows VM. This may not be a big deal if you only have 100 View desktops (= 10 extra GB of storage), but if you have 1,000 or 10,000, it’s something to consider.
The View Storage Accelerator is a feature of vSphere 5.0’s Content-Based Read Cache design (CBRC). That’s right, vSphere…not View. However, View is the perfect use case for the host caching feature, as much of the same content can appear across disks that are utilized for a View environment. In very simple terms, by using what VMware refers to as Online Caching and Offline Hashing, VMware is able to store commonly used content in a RAM buffer cache. It applies hashes to this content and, if a VM makes an I/O read request that has a valid hash, it can grab the content from the RAM buffer cache. If the content requested doesn’t have a valid hash, the VM will need to grab it from the original storage (datastore). To find out details of this process, please refer again to VMware’s View Storage Accelerator white paper (PDF).
Although the CBRC workflow can sound a little complicated, implementing the View Storage Accelerator feature is quite easy. It is not enabled by default, so you must go into the View Administrator web UI to enable it manually in two places: the vCenter settings and the pool settings. Here’s how to do it.
- Log in to the View Administrator Web UI.
- Expand View Configuration on the left and click Servers.
- For each vCenter server, highlight it and click the Edit button.
- Click the Host Caching tab and put a check next to Enable Host Caching for View (Figure A). (Read this post by Andre Leibovici to learn more about sizing your host cache.) You can change the host cache for each individual host under this tab as well, if you like.
- Click OK.
- Under Inventory on the left side, click Pools.
- Select the pool(s) on which you would like to enable Host Caching.
- Click Edit.
- Click the Advanced Storage tab and put a check next to Use Host Caching (Figure B).
- If you are using persistent disks, you can change the Disk Types drop-down menu to say OS Disks and Persistent. If not, just leave it as OS Disks.
- The default is to regenerate cache after seven days. You don’t want to make this period too short, as you want to have a number of valid hashes (content) in your CBRC cache.
- Choose blackout times in the Advanced Storage tab if you like. Blackout times allow you to only run Host Caching during the business day or during certain off-peak hours. This will help with performance during peak hours.
- Click OK.
Figure A
Figure B
If you enable Host Caching on an already existing pool, it is recommended that you recompose them to a new (preferably optimized for View) base image so the base disk has caching enabled from the beginning. Also, the VMs (desktops) must be restarted manually for this to take effect.