eG Monitoring
 
Measures reported by PVSStoreTest

A store is the logical name for the physical location of the vDisk folder. This folder can exist on a local server or on shared storage. When vDisk files are created in the console, they are assigned to a store. Within a site, one or more Provisioning Servers are given permission to access that store in order to serve vDisks to target devices.

When a user attempts to access a desktop from a client, if the vDisk mapped to that client is inactive/locked, then such a user may be denied access to the desktop. To prevent such disasters, administrators need to promptly identify inactive vDisks and locked vDisks, and also figure out how many target devices are connecting to these vDisks, so that they can easily assess the extent of damage that this may cause. In addition, an improperly sized write-cache can also add to the monitoring troubles of administrators, as the cache may grow too big and start choking the vDisk! The size of the write-cache should hence be tracked continuously and consistent growth in size should be brought to the attention of the administrators instantly. This is where the PVSStoreTest test helps. For every vDisk in a store, this test reports whether/not that vDisk is active, locked, and mapped to target devices. If mapped, the test additionally reports the number of devices to which that vDisk is mapped. This way, the test promptly alerts administrators to the abnormal state of a vDisk and also informs administrators as to how many devices will be affected by this abnormality. Additionally, the test also periodically reports the write cache size and type of every vDisk, thus quickly intimating administrators of unexpected growth in the write-cache size, and enabling them to rapidly initiate investigations.

The measures made by this test are as follows:

Measurement Description Measurement Unit Interpretation
Is_vdisk_locked Indicates whether/not this vDisk is locked.   Since multiple target devices and Provisioning Servers can gain access to a single vDisk image file, it is necessary to control access to prevent corruption of the image. Should a user accidentally assign a private image to multiple target devices, and then try to boot those target devices, a corrupt image would result. Therefore, the image becomes locked appropriately for a given configuration. Target devices/Provisioning servers cannot access locked vDisks.

If the vDisk is locked, then this measure will report the value Yes. If not, it will report the value No.

These measure values and their corresponding numeric values are listed in the table below:

Measure Value Numeric Value
Yes 1
No 0

Note:

By default, this measure reports the values Yes or No to indicate the lock status of a vDisk. The graph of this measure however, represents the lock status using the numeric equivalents - 0 or 1.

Be aware that under certain circumstances these locks may not be released properly. A lock on a vDisk image may not be released properly when a target device machine is booted from a vDisk, and then fails (or power is lost). If the same target device boots again, the same lock is used and no problem occurs. However, if an administrator tries to mount the drive on the Provisioning Server after the target device has failed, the Provisioning Server will not be able to mount that vDisk because a lock is still held by the failed target device. The Administrator has the capability to release these locks.

To view the details of the lock, use the detailed diagnosis of this measure.

Is_device_active Indicates whether/not this vDisk is active.   If the vDisk is active, then this measure will report the value Yes. If not, it will report the value No.

These measure values and their corresponding numeric values are listed in the table below:

Measure Value Numeric Value
Yes 1
No 0

Note:

By default, this measure reports the values Yes or No to indicate the current state of a vDisk. The graph of this measure however, represents the same using the numeric equivalents - 0 or 1.
Is_device_mapped Indicates whether/not this vDisk is mapped to a target device. MB If the vDisk is mapped to a target device, then this measure will report the value Yes. If not, it will report the value No.

These measure values and their corresponding numeric values are listed in the table below:

Measure Value Numeric Value
Yes 1
No 0

Note:

By default, this measure reports the values Yes or No to indicate whether/not the vDisk is mapped. The graph of this measure however, represents the same using the numeric equivalents - 0 or 1.
Disk_size Indicates the size of this vDisk. MB Depending upon the file system used to store the vDisk, the maximum size of a vDisk is 2 terabytes (NTFS) or 4096MB (FAT).
Device_count Indicates the number of target devices that are currently connected to this vDisk. Number To know the names of the devices that are currently connected to a vDisk, their IP address, the site in which they operate, and the store they use, take the help of the detailed diagnosis of this measure.
Write_cache_size Indicates the current size of the write cache of this vDisk. MB When using Citrix Provisioning Services with the vDisk in standard mode you have a write-cache drive location that holds all the writes for the operating system. If the write-cache file is not properly sized, it may fill up unexpectedly; in this case, the operating system will behave the same as if the drive ran out of space without any warning, in other words it will blue screen.

The optimum size of write-cache drive depends on several factors:

  • Frequency of server reboots. The write-cache file is reset upon each server boot so the size only needs to be large enough to handle the volume between reboots.
  • Amount of free space available on the c: drive. The space that will be used for new files written to the c: drive is considered the free space available. This is a key value when determining the write-cache drive size.
  • Amount of data being saved to the c: drive. Data that is written to the c: drive during operation will get stored automatically in the write-cache drive. New files will be stored in the write-cache file and decrease the amount of available space. Replacements for existing files will also be written to the write-cache file but will not marginally affect the amount of free space. For instance, a service pack install on a standard-mode disk will result in the write-cache file holding all the updated files, with very little change in available space.
  • Size and location of the pagefile. When a local NTFS-formatted drive is found, Provisioning Services moves the Windows pagefile off of the c: drive to the first available NTFS drive, which is also the location of the write-cache file. Therefore, in the default configuration, the write-cache drive will end up holding both the write-cache file and the pagefile.
  • Location of the write-cache file. The location of the write-cache file is also a factor in determining its size. The write-cache file can be held on the target device's local disk, the target device's RAM, or on the streaming server.

    • Target device disk: If the write-cache file is held on the target device's disk, it could be a local disk to client, local disk to the hypervisor, network storage to the hypervisor, or SAN storage to the hypervisor.
    • Target device RAM: If the write-cache file is held in the target device's RAM the response time will be faster and in some cases the additional RAM is less expensive than SAN disk.
    • Streaming Server: If the write-cache file is on the server, no preset size is necessary. When using server-side write-cache file, the Provisioning Services streaming server must have enough disk space to hold the write-cache files for all target devices managed.

Below are a few guidelines for right-sizing the client-side write-cache drive.

  • Write-cache drive = write-cache file + pagefile (if pagefile is stored on the write-cache drive)
  • Write-cache file size should be equal to the amount of free space left on the vDisk image. This will work in most situations, except those where servers receive large file updates immediately after booting. As a rule, your vDisk should not be getting updated while running in standard-mode.
  • Always account for the pagefile location and size. If it is configured to reside on the c: or d: drive, include it in all size calculations.
  • Set the pagefile to a predetermined size to make it easier to account for it. Letting Windows manage the pagefile size starts with 1x RAM but it could vary. Manually setting it to a known value will provide a static number to use for calculations.
  • During the pilot, use server-side write caching to get an idea of the maximum size you might see a file reach between server reboots. Obviously, the server should have a full load and should be subject to the normal production reboot cycle for this to be of value.

In most situations, the recommended write-cache drive size will be free space available on vDisk image plus the pagefile size. For instance, if you have a 30GB Windows Server 2008 R2 vDisk with 16GB used (14GB free) and are running with an 8GB pagefile, it would be good practice to use a write-cache drive of 22GB calculated as 14GB free space + 8GB for the pagefile. If space doesn't permit, you have a few options, not all of which may be available to you.

  • If storage location for the write-cache drive supports thin-provisioning, configure thin-provisioned drives for the write-cache drive to save space;
  • Use dynamic VHDs (instead of fixed VHDs) though this approach is generally only recommended for XenDesktop workloads. If you choose this approach, you will probably need to periodically reset the size of the dynamic VHD, which can be done with a PowerShell script.
  • Reboot the servers more frequently which in turn will reduce the maximum size of the write-cache file.
  • Move the pagefile to a different drive or run without a pagefile.
Write_cache_type Indicates the write-cache type for this vDisk.   The values that this measure reports and their corresponding numeric values are detailed in the table below:

Measure Value Numeric Value
Private 0
Cache on Server 1
Cache in Device RAM 3
Cache in Device Hard Drive 4
Device RAM Disk 6
Cache on Server Persistent 7
Cache in device RAM with overflow on hard disk 9

Note:

By default, this measure reports the Measure Values listed in the table above to indicate the write-cache type. In the graph of this measure however, the same will be represented using the numeric equivalents only.

vDisk_assigned Indicates the number of target devices that have been assigned this vDisk. Number Use the detailed diagnosis of this measure to know which target devices have been assigned this vDisk.
LockedDuration Indicates the duration for which this vDisk has been in the locked state. Mins Since multiple target devices and Provisioning Servers can gain access to a single vDisk image file, it is necessary to control access to prevent corruption of the image. Should a user accidentally assign a private image to multiple target devices, and then try to boot those target devices, a corrupt image would result. Therefore, the image becomes locked appropriately for a given configuration.

Target devices/Provisioning servers will not be able to access locked vDisks until the lock is released. This is why, a very low value of this measure is ideal.

Replication_status Indicates the current replication status of this vDisk.   The values that this measure reports and their corresponding numeric values are detailed in the table below:

Measure Value Numeric Value
Up to date 1
Not up to date 0

Note:

By default, this measure reports the values Yes or No to indicate the current replication status of this vDisk. The graph of this measure however, represents the same using the numeric equivalents - 0 or 1.

This measure will report Up to date only when the GoodInventoryStatus and the CanPromote: Read-only fields return a value of true.