Configuring Storage Accelerator in View 5.1

Configuring Storage Accelerator in View 5.1

VMware View Storage Accelerator

VDI deployments are scaling up nowadays by increasing backend computing power and by adding up storage space for desktop consolidation. Storage space keeps the Virtual Machine Images which loads to the host memory to make the desktops live. One of the performance bottleneck involved here is the I/O requests issued from Virtual Machines to the underlying storage for accessing the data contents from Virtual Machine images. VMware View 5.1 comes with View Storage Accelerator to address this bottleneck by optimizing the Storage IOPS. This feature leverages Content Based Read Cache (CBRC) implemented in vSphere and controlled through Host Caching configuration of VMware View. The CBRC provides a per-host RAM-based solution for View Desktops. This considerably reduces the read I/O requests that issues to the storage layer by serving the cached content directly from the host's reserved RAM buffer

By enabling Storage Accelerator each View Desktop's virtual disk file is configured and attached with a "digest" file. This digest is created per VMDK and is loaded to ESX host's memory. When a VM issues read requests, the requested block is cached to a per-host RAM buffer then copied to VM buffer. When VM issues read request for same content it first identifies the valid block contents by referring to the digests. In case of valid block, content is served directly from the ESX host's RAM buffer instead of sending I/O request to storage layer.

This offers considerable benefit when loading favorite applications in VMs, as the cache is a "Content Based". In case of linked clone pools, the digest is created as per the linked clone tree structure. This way it helps in reducing storage I/O storm during VM boot.

This document details about enabling Storage Accelerator by configuring "Host Caching" option in VMware View 5.1

Configuring Host Caching

In VMware View 5.1, Host Caching configuration is done at two levels

  1. vCenter server settings of View Administrator.
  2. Advanced Storage settings of a desktop pool.

The former configuration is a general policy about the use of host caching on hosts controlled by the vCenter. It is a quick way of disabling host caching for all VMs in that vCenter. Once the vCenter is capable of host caching latter one enables VM to use the host caching.

vCenter Server Settings

Host caching is configured and applied per-vCenter basis.  Navigating to VMware View Administrator left panel inventory – Servers – vCenter Server lists all the vCenter added to the View administrator. Edit the vCenter server and go to Host caching tab to enable host caching.  These options are also available while adding a new vCenter Server. See figure 1 below


Figure 1: Enabling host caching for a vCenter Server in View Administrator

When host caching is enabled for a vCenter server through this wizard, all supported vSphere hosts (vSphere 5.0 or later) those are part of the vCenter server, are identified as Host caching capable hosts. All these hosts will be listed under ‘hot Cache settings’. If one specific host’s cache configuration needs to be changed, then it can override by setting a custom value. Select the specific host and click on “Edit cache size…”, and select ‘Override default host cache size’ and input new cache size value.


Figure 2: Overriding default host cache size

The  cache value must be in between 100MB to 2048 MB. Refer Figure 2. Note  that, the host cache settings cannot be disabled for a specific host.  

These configurations can also be done for an added vCenter server, by  editing vCenter server settings and navigating to ‘Host Caching’ tab. Note: Though host caching parameters are configured through View  administrator UI, configuration is not performed on a vSphere host until  and unless a host caching enabled VM uses the host. These settings will  applied to vSphere only if the host is used by at least one VM on a  pool that is configured for host caching

Configuring desktop pool to use Host Caching

Once the host caching is enabled at vCenter level then any desktop pools that is deployed in the vCenter, (except terminal server pool and physical machine pool) provides “Use host caching” configuration. During Pool create wizard this option can be enabled at ‘Advanced Storage Options’ page. Figure 3 below shows how to enable “Use host caching” during automated linked clone pool add wizard.



Figure 3: Configuring a new automated linked clone pool to use host caching

The same configuration can be performed by editing an existing desktop pool but host cache configuration changes of the pool are applied only when the VM is powered off.  If host caching is disabled at vCenter server settings page, ‘Use host caching’ option will not be activated for the pool. It is also allowed to edit the pool settings to turn off host caching. Each pool settings are explained below. VMware recommends configuring host caching during the pool creation time.

Use host caching

This option enables all the VMs in the pool to use host caching configured for the vCenter. If VMs are powered on, these settings will not apply immediately and waits for VMs to be in powered off state. When this configuration is applied to a pool VM, in the backend at vSphere, a digest disk is created with metadata and hashes. When the VM next powers on the digest is loaded to the metadata cache. If VMs issues read request, it first checks the metadata cache for a valid block and if found the data block is served directly from the vSphere common cache. If multiple VMs issues read requests for similar data content all those are served from this shared per-host cache.

Disk Types

This defines the VMDK disk type of the pool VM that will to be used for host caching. This setting is valid only for linked clone pool with User Data redirection. By default only the boot VMDK of the pool VM is selected for digest creation and online caching. This is referred as ‘OS disks’ in pools settings. In case of automated linked clone pool with user data redirection, each pool VM will have an additional persistent disk to store user data. Drop down the ‘Disk Types’ option to choose ‘OS and persistent disks’ so that both User data disk VMDK and book VMDK are enabled for host caching

Regenerate Cache

This defines the scheduled interval to perform digest recompute. During pool-VM’s life time, write activity to the VMDK can occur, which will result large number of invalid hashes in the digest. Data blocks corresponding to these invalidated hashes will not be cached.  So for a continuous benefit, it is important to reduce the number of invalid hashes in the digest by performing digest recompute periodically. The default is 7 days.

Blackout times

This defines recurring schedule for which the cache regeneration should  not be performed. This option allows the administrator to plan the  'digest recompute' to run only during non-business hours, off-peak  schedule etc. Refer figure 4. Here the cache regeneration is not  performed during 9 AM to 6 PM on all week days



Figure 4: Setting restriction period for cache regeneration

Also administrator is allowed to add a list of multiple black out time  and /or days. These list entries can be further modified or removed.   This can be done through the blackout time table in host caching wizard.  Refer the table in figure 3. The “Add”, ‘Edit” and ‘Remove” options  below this table can be used.

VM Host caching status

View administrator UI displays per VM host caching status. Navigate to ‘Inventory’ – ‘Desktops’ and double-click on a desktop VM for VM summary page. Select the vCenter settings TAB. Here the in ‘General Box ‘Host Caching’ represents the status of the host caching.  Each status is explained below.

  1. Off: The host caching status is shown as off if is not configured for Host caching or should not be configured to use host caching.
  2. Current: If the host caching is enabled and valid digests are cached, status shows current. This represents VM is configured to use Host Caching and digests are upt-to-date.
  3. Out of date: Due to VM life cycle digests can be invalid over a period of time and status will display Out of date. This means VM is configured to use host caching but digest is out of date and needs regenerating.
  4. Error: Displayed only when something goes wrong with VM Host caching or CBRC operation. This is cleared by next successful operations.

Why would the Host Caching Status still show as 'Off' even after I've enable it in vCenter settings and at the pool level, powered off the VM, and saw that vCenter created a virtual disk digest for that VM?



How to turn off the non-stop messages about "recompute virtual disk digest" and "update option values" in the vCenter task bar? Unable to see any other messages because these two messages appear constantly. Attempted to uncheck the "Enable CBRC" box in host settings, but the messages continue to appear. Any help will be appreciated.


Host Cahching configuration applies to VM when it is in powered off state. The digest disk can be created only during powered off state

Hi how frequently it shows ? based on any VM action ?

Have this vCenter added in any other View connection server ?

I have the same complaint as ccipl01.  I have two connection servers, and every minute one of them is executing a "Recompute virutal disk digest" task.  It is a new install and am mostly wondering if this is normal behavior.

I have the same issue, several per minute, every minute.  They drown out all other events.  I don't even have Storage Accelerator turned on on either of my pools.  Did any of you figure out what was causing this?

Mine stopped doing it on its own.  Possibly after a recompose, i don't remember when it stopped.

I was able to fix this issue today, after realizing that we have 2 View environments (5 and 6) using the same vCenter. I had enabled View Storage Accelerator on version 6 only, as 5 is soon to be decomissioned. I understand that while View 6 was enabling the advanced options for CBRC on each of the ESXi hosts in the cluster, the old View environment was disabling it. They both kept fighting until I enabled the feature on View 5. Please note the changes won't take effect until at least one VM in the environment is using the feature. Easier way to do that is to power off one VM and wait some time.

Version history
Revision #:
1 of 1
Last update:
‎05-18-2012 03:16 AM
Updated by: