PVS Stores Test

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 PVS Stores 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.

Target of the test : Citrix Provisioning server

Agent deploying the test : An internal agent

Outputs of the test : By default, the test reports one set of results for every vDisk in every store in the PVS farm being monitored

Configurable parameters for the test
  1. TEST PERIOD – How often should the test be executed
  2. Host – The host for which the test is to be configured
  3. Port – Refers to the port used by the Citrix Provisioning server. By default, this is 54321.
  4. mcli path – This test executes commands using the Management Command Line Interface (MCLI) of the Provisioning server to collect the required metrics. To enable the test to execute the commands, the eG agent, by default, auto-discovers the full path MCLI.exe on the target Provisioning server. This is why, the mcli path is set to none by default. If, for some reason, the eG agent is unable to auto-discover the mcli path, then you will have to manually specify the path here using the following pointers:

    • Typically, in a 32-bit Windows system, the MCLI.exe will be available in the following location by default: <System_Root>\Program Files\Citrix\Provisioning Services Console
    • In a 64-bit Windows system on the other hand, the MCLI.exe will be available in the following location by default: <System_Root>\Program Files (x86)\Citrix\Provisioning Services Console
  5. domain name, domain user and domain password – To report farm-related metrics, this test should run using the credentials of a user who fulfills the following requirements:

    • Should belong to the Security group with 'Farm Administrator' access.
    • Should be assigned the Allow log on locally security privilege on the Citrix Provisioning Server host.

    The steps for assigning such privileges to a user are detailed in the Pre-requisites for monitoring the Citrix Provisioning Server topic.

    Once you assigned the aforesaid privileges to the user, then configure this test with the domain name, domain user, and domain password of the same user.

  6. local host only - By default, this flag is set to Yes. This implies that, by default, the test reports metrics for the target server that is being monitored. Setting the flag to No ensures that the test auto-discovers all the servers that are part of the PVS farm, and reports metrics for each server in the PVS farm.
  7. detailed diagnosis - To make diagnosis more efficient and accurate, the eG Enterprise embeds an optional detailed diagnostic capability. With this capability, the eG agents can be configured to run detailed, more elaborate tests as and when specific problems are detected. To enable the detailed diagnosis capability of this test for a particular server, choose the On option. To disable the capability, click on the Off option.

    The option to selectively enable/disable the detailed diagnosis capability will be available only if the following conditions are fulfilled:

    • The eG manager license should allow the detailed diagnosis capability;
    • Both the normal and abnormal frequencies configured for the detailed diagnosis measures should not be 0.
Measurements made by the test
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.

 

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.

vDisk 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).

Target device connections

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 to target devices

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.

Locked duration

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 state of a 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.

The detailed diagnosis of the Is vDisk locked? measure reveals the site name, internal name of the locked vDisk, the full path to the original vDisk file, and the name of the server where the store containing the vDisk exists.

Figure 2 : The detailed diagnosis of the Is vDisk locked? measure