Configuring Storage Accelerator in View 5.1

Version 8

    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.