Personal vDisk and IO redistribution

With the persistent (assigned) desktop configuration utilizing Citrix personal vDisk, the effect of I/O to the storage can be summarized as follows:

  • Much of the workload that went to the write cache in a nonpersistent desktop now goes to the personal vDisk. Write cache workload is much lower in a persistent environment.
  • Per Citrix, the personal vDisk driver on the guest machine contains a small read cache. This results in 10-20% decrease in total operations to the storage over nonpersistent desktops.

The amount of I/O that the personal vDisk incurs will be highly variable and dependent the applications that are installed on the individual desktops. The I/O is affected by the type of application installed on the personal vDisks in the environment and where that data is stored. As an example, a desktop environment that uses highly I/O intensive applications or performs copy or compression of large files will see much higher I/O to the personal vDisk storage than an environment that only runs word processing or spreadsheet applications.

In our LoginVSI testing most of the applications were installed on the golden image; therefore, the majority of reads were serviced from the PVS server cache instead of the personal vDisk storage. This will naturally give best results in terms of storage resource utilization and efficiency. The user data written by the Login VSI applications was contained mostly on the CIFS user data storage. The personal vDisk handled mostly OS level changes to the file system.

In a persistent configuration, most of the workload that was serviced by the write cache is now divided among the personal vDisk storage and the CIFS user data if profile management software is in use. One major difference that is observed when using CIFS for user data is that additional overhead of CIFS metadata operations is incurred. This is because of the client’s data being contained on file-based storage rather than its block-based vDisk or VMDK.

The following is a breakdown of IOPs per desktop in each of the persistent (assigned) desktop use cases.

io pvdisk

The total I/O seen in tests with only personal vDisk enabled shows less total I/O to storage than in the nonpersistent tests. A peak average of eight total IOPs was incurred, with two going to write cache and six being served from the personal vDisk storage. The reason for this is that personal vDisk adds an additional read cache at the guest driver layer which slightly decreases the amount of I/O served from storage.

Adding CIFS profile management and home directories into the environment takes some I/O from personal vDisk and adds it to CIFS. The additional metadata operations necessary for SMB file access makes up the remainder.

After the personal vDisk and CIFS user data is configured in a PVS environment, the write cache is mostly relegated to handling operations to the guest OS page file and its I/O is greatly reduced. Most of the I/O to the OS and application files will now be served from the PVS server cache, the personal vDisk storage, and CIFS home directories and sizing and planning should be adjusted accordingly.

The graphs below summarize the breakdown of read and write operations to the personal vDisk and write cache storage during boot and login scenarios for persistent desktops. Again, as in all cases the workload was approximately 90% writes.

500-seat boot and login, I/O comparison, PVS with personal vDisk.

pvdisk io 1 pvdisk io 2

About zhurachel

I am a solution architect focus on virtualization and storage.
This entry was posted in virtual desktop and tagged , , , , , , , , , . Bookmark the permalink.

1 Response to Personal vDisk and IO redistribution

  1. Walter scott says:

    Good article

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.