Provisioning Services – Cache Options

How to access these options?

These cache options I have previously mentioned can be accessed via the properties of the vDisk. (To create one go to Store, right click and choose create a new vDisk)


Under access mode, if it is showing Private Image, cache type will be grayed out which is saying vDisk is currently in used and you can’t change this option. When you change the Access mode to Standard Image then you have options available;



Citrix Provisioning Services PVS

Citrix Provisioning Services (PVS) allows you to have a single instance image management of your XenApp and/or XenDesktop VMs. A single image means you only have to update a single image which is then streamed to hundreds of desktops.

In a production environment, PVS consists of at least two PVS servers for High Availability. A disk image is taken from a reference computer which has been built up with all patches, applications etc installed and configured, and the vDisk image is imported into PVS. The imported vDisk image usually sits on locally attached storage on each PVS server. ‘Target device’ VMs are created without a C: drive and set to boot from network. The MAC addresses of the VMs are added to the PVS database so that when the VMs PXE boot the PVS server knows which vDisk to provide. The first time a vDisk is streamed to a target device the vDisk is cached in memory on the PVS server.

Since we are streaming a single vDisk to multiple computers, the vDisk must be read-only to avoid corruption. But Windows can’t run off a read-only disk, so thanks to Citrix  PVS to have a ‘write cache’ . There is also default location for the write cache, however it is very slow and not ideal under high availability. Attaching a small (10GB) disk to each VM for the write cache is a good approach – this disk can reside on local host storage, the SAN. When the PVS target device reboots, the write cache is cleared so each boot is a ‘first boot’. To ensure there is no data loss, use redirected folders and a good profile management system. Since PVS 7.1, Citrix introduced a new write cache option called ‘Cache in device RAM with overflow on hard disk’. The option takes a chunk of VM memory and uses it as a disk cache which provides a massive performance boost over other write cache options.

Let me go through Write Cache options that Citrix PVS offers;

Write Cache in Provisioning Services Server

In PVS, the term “write cache” is used to describe all the cache modes. The write cache includes data written by the target device. If data is written to the PVS server vDisk in a caching mode, the data is not written back to the base vDisk. Instead, it is written to a write cache file in one of the following locations:

  • Cache on device hard disk
  • Cache in device RAM
  • Cache on device RAM with overflow on hard disk
  • Cache on server

When the target device is booted, write cache information is checked to determine the presence of the cache file. If the cache file is not present, the data is then read from the original vDisk file.
All current versions of PVS have the option for distributing write cache. It is called Multiple Write Cache Paths. The multiple write cache paths (for a store) option provides the capability of distributing the write cache files across multiple physical media. This feature helps to improve I/O throughput for heavily loaded servers.
When a target device starts the server chooses one of the write cache paths from the list based on the MAC address of the client. The goal of selecting a path based on the MAC address is to get an even distribution of the clients across the available paths. The algorithm selects the same path for a given client each time that client is booted.
This functionality is needed to ensure that during a High Availability (HA) failover the new server would choose the same write cache for the client (otherwise it would not be able to find the write cache file and the client would hang). If the defined write cache path is not available to a server, the server falls back to the standard vDisk path.
It is not recommended for the Cache on the server to be used in production environments.

Cache on device Hard Disk


  • Local HD in every device using the vDisk.
  • The local HD must contain Basic Volume pre-formatted with a Windows NTFS file system with at list 512MB of free space.

The cache on local HD is stored in a file on a secondary local hard drive of the device. It gets created as an invisible file in the root folder of the secondary local HD. The cache file size grows, as needed, but never gets larger than the original vDisk, and frequently not larger than the free space on the original vDisk. It is slower than RAM cache, but faster than Server cache and works in a HA environment.

Cache in device RAM


  • Appropriate amount of physical memory on the machine.

The cache is stored in client RAM (memory). The maximum size of the cache is fixed by a setting in vDisk properties. All written data can be read from local RAM instead of going back to the server. RAM cache is faster than cache on server and works in a HA environment.
Note: If more different sectors are written than the size of the cache, the device stops.

Cache on device RAM with overflow on Hard Disk


  • Provisioning Service 7.1 or later.
  • Windows 7, Windows Server 2008 R2 or later.
  • Local HD in every device using the vDisk.

When RAM is zero, the target device write cache is only written to the local disk. When RAM is not zero, the target device write cache is written to RAM first. When RAM is full, the least recently used block of data is written to the local Write Cache disk to accommodate newer data on RAM. The amount of RAM specified is the non-paged kernel memory that the target device consumes.

Cache on Server


  • Enough space allocated to where the server cache will be stored.
Server cache is stored in a file on the server, or on a share, SAN, or other location. The file size grows, as needed, but never gets larger than the original vDisk, and frequently not larger than the free space on the original vDisk. It is slower than RAM cache because all reads/writes have to go to the server and be read from a file. The cache gets deleted when the device reboots, that is, on every boot the device reverts to the base image. Changes remain only during a single boot session. Server cache works in a HA environment if all server cache locations to resolve to the same physical storage location. This case type is not recommended for a production environment.