eG Monitoring
 

Measures reported by VmgPVSWCacheTest

Provisioning Services (PVS) is a service utilized to stream an operating system image from a file, known as a vDisk, to a physical or virtual computer. The recipient of the stream can be a disk less computer with the vDisk acting as its hard disk drive. One of the primary benefits of PVS is the ability to utilize a single vDisk to stream to multiple computers. This type of vDisk is known as a Standard vDisk and offers increased consistency, security, and centralized management.

Standard vDisks are Read-Only. All modifications, such as application installations, are written to a temporary file known as the Write Cache. When read requests for the newly written files come in, they are read from the write cache.

The Write Cache file can be configured to reside in the following locations:

  • Cache on device hard drive: Write cache can exist as a file in NTFS format, located on the target-device's hard drive. This write cache option frees up the Provisioning Server since it does not have to process write requests and does not have the finite limitation of RAM.

  • Cache in device RAM: Write cache can exist as a temporary file in the target device's RAM. This provides the fastest method of disk access since memory access is always faster than disk access. This measure will report metrics only if the cache resides in the device RAM.

  • Cache in device RAM with overflow on hard disk (only available for Windows 7 and Server 2008 R2 (NT 6.1) and later): In this case, 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 differencing disk to accommodate newer data on RAM. The amount of RAM specified is the non-paged kernel memory that the target device will consume.

  • Cache on server: Write cache can exist as a temporary file on a Provisioning Server. In this configuration, all writes are handled by the Provisioning Server, which can increase disk IO and network traffic.

  • Cache on server persistent: This cache option allows for the saving of changes between reboots. Using this option, after rebooting, a target device is able to retrieve changes made from previous sessions that differ from the read only vDisk image. If a vDisk is set to Cache on server persistent, each target device that accesses the vDisk automatically has a device-specific, writable disk file created. Any changes made to the vDisk image are written to that file, which is not automatically deleted upon shutdown. This saves target device specific changes that are made to the vDisk image.

For virtual servers, administrators typically use the server's hard drive for storing the write cache. Storing the write cache on the target side is beneficial as it keeps the write “close” to the target and minimizes the load on the Provisioning Servers, but it requires more resources. If the write-cache does not have enough disk space resources to grow, then many modifications to the vDisk will be lost. This is why, it is imperative that the write-cache is sized right, its usage is tracked continuously, and the lack of adequate disk space for the write cache brought to the attention of administrators rapidly. This is what the VmgPVSWCacheTest does! This test monitors the size and usage of the write cache and proactively alerts administrators when the write-cache runs out of space.

Note:

This test will report metrics only if the write-cache resides in one of the following locations:

  • Cache on device hard drive

  • Cache on server

  • Cache on server persistent

Outputs of the test: One set of results for the provisioned Virtual server being monitored.

The measures made by this test are as follows:

Measurement Description Measurement Unit Interpretation
Write_cache_size Indicates the current size of the write cache. GB

 
Write_cache_util Indicates the percent usage of the write cache. Percent

The value of this measure is computed using the following formula:

(PVS Write Cache Max Size - Write cache size) / Write cache size * 100

If the value of this measure is close to 100%, it indicates that the write cache may soon run out of space. Under such circumstances, you have the following options:

  • You can increase the maximum size to which write cache can grow, or;

  • Redirect some items out of the write cache and into a persistent drive.

Before increasing the maximum write cache size, you will have to take the following into account:

  • Basically the write cache will store all writes which would have gone to the hard disk. So if a user tends to copy large files locally to his/her desktop the write cache will grow at the same pace as the files are transferred. If there is any application which caches files or portions of a central DB locally for better performance, then the write cache will grow again.

  • But there are some items which will always hit the write cache and these are split into two areas again. On one hand there is the user space, which contains items such as the user profile or internet/application related temp files. The user related write cache disk space needs to be multiplied by the amount of users logged on to a particular system.

  • On the other hand we have the system space, which contains items such as logs or system temp / cache files, but we will also find files which are modified by the OS or any service for whatever reason. The system related write cache disk space is typically larger for server operating systems than for workstations.

If you choose to redirect, then one/more of the following items can be redirected:

  • Windows Pagefile. In fact the PVS Target Device driver detects if a local drive is available and redirects the pagefile automatically.

  • Windows Event Log. While the eventlog is typically quite small (maybe 100MB or so) many customers redirect it for supportability and traceability reasons.

  • Citrix related logs. Same as Windows Event Log.

  • Anti Virus pattern. In case the virus scanner allows redirecting the pattern file, doing so saves some write cache space but it also saves some network traffic as it is not required to load the pattern from scratch after every reboot.