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!
Citrix Provisioning Services (PVS) is a great tool that is what our local Citrix Sales Engineer calls “the Secret Sauce” behind XenDesktop. For those who are new around these parts, PVS is software that allows us to stream an Operating System to a PC, physical or virtual, ESX or Hyper-V or XenServer – anything that can PXE boot pretty much (including Thin Clients!).
Once you’ve made the plunge and start deploying or planning your PVS infrastructure, High Availability and Redundancy is going to be a top concern. Here are a few guidelines to help you plan. Let’s assume we have a single farm, single site, with 2 Provisioning Servers.
Shared storage is your friend with Provisioning Server HA.
vDisk Storage
Ideally, this should be on shared storage. Server should be able to communicate with the SAN/NAS/etc at high speed. Fibre Channel works great here (4Gbps). Alternatively, you can have identical vDisks available via the same drive letter on each of the servers.
Write Cache Location & Storage
The two types of write cache locations that are in play: Stored on PVS Disk and Stored on Client HD (ignore Encryption, it’s not really relevant here). Storing the Write Cache on the Client’s Hard Drive is fastest, and is what I would recommend, as the file is available independent of the provisioning server. Alternatively, you can store the write cache on shared storage that can be accessed by each server so that the target device can continue to function.
TFTP Server
This is the tricky part. The best way to handle this is with hardware load balancers, but for the sake of this article, I’ll give you some “rigging” solutions. You can run the TFTP service on both servers and use “round-robin” settings on your DHCP server. Also, you can use the Bootable Image tool included with PVS to create a Bootable CD that contains the bootstrap file (the same one that it can get via PXE). If you have a NetScaler in your environment, you can use it to ensure HA of TFTP (Thanks Bart Groot Zevert). I’m sure there are other ways as well, feel free to comment with suggestions.
Conclusion
As mentioned before, these are just some guidelines and tips to get you started on the right path. I’ll be more than happy to assist should you need assistance.
Planning for your new XenDesktop environment can be a tough process. Being a relatively fresh technology, there aren’t too many places to find straight answers regarding scalability. I intend on changing that. Here are a few helpful tips and straight answers to help you decide whether you have the hardware already, or need to purchase new. This will be a multi-part series, only some aspects will be addressed in this initial post.
Assumptions
While this scenario is pretty simple, I’ll be more than happy to help you with your questions in the comments, via Twitter, or e-mail.
In the next post, I’ll discuss Virtual Machine Specifications and choosing the right server specifications for your XenServer hosts.
I’m often asked how to update a vDisk for use with XenDesktop, so I figured I should publish my answer.
These steps should suffice to answer most questions regarding updating vDisks for XenDesktop. I’ll be happy to assist you if you have more questions or require clarification. Just leave a comment.