vDisk Modes for Provisioning Server 5.1

A brief overview and common use cases.

When configuring your vDisks in Citrix Provisioning Server, you’re able to define which mode you would like your vDisk to be in. While many people know the basic differences, not everyone understands how to leverage them in their environment.

Private Mode

Private mode puts the vDisk into a volatile state where a target device can make permanent changes to the vDisk. Changes are not stored in a write cache file, they are changed immediately. When a target device connects to the vDisk, it gains exclusivity and no other device may connect to that vDisk.

This mode is best used when a single user needs application install capabilities which need to persist through reboots and updates. This is idea for streaming an operating system to a physical target device in order to move their hard disk to the datacenter for data consolidation. This mode is also used to make changes to a vDisk that is otherwise in Standard or Difference mode.

Standard Mode

Standard Mode is the bread and butter of Provisioning Server. It allows for changes made by the user, but they do no persist through reboots. They are stored in a write cache file and cleared upon graceful shutdown. The location of the write cache file is defined on a per vDisk basis and can be placed on the Provisioning Server Disks, in the target device’s RAM or local disk – with options for encryption and maximum size (when placed in RAM).

Standard Mode is usually used when leveraging XenDesktop so that users receive a standardized desktop which they can make temporary changes to without affecting the experience of other users. This can also be used when streaming an OS to a desktop to turn it into a pseudo thin client.

Difference Mode

Difference Mode is an interesting mode. It’s not often used, as far as I know. It’s essentially a hybrid standard-private vDisk. The base of the image is standard, but the user can make changes which are stored in a write cache file just like standard, but they persist through reboots. When the target device is booted, it boots to the standard image and then the write cache file is applied like a delta file. The main issue with this is when a change is made to the standard base, it destroys the delta write cache files.

Possible uses include tech labs and classes where a standard environment must exist for all users, but users need to make changes as part of the curriculum. The instructor can then remove the write cache files and “reset” the environment. A serious time saver in that case.

Conclusion

I only listed a few short use cases in this post. I’m really curious how everyone leverages these modes in their environment – please share!