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!

Provisioning Server 5.1 High Availability Tips

Basic Guidelines to Help Ease the Pain During Implementation

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.

Hardware Planning Tips for XenDesktop 3.0, Part 1

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

  • XenDesktop 3.0, Platinum Edition.
  • XenServer 5.5.
  • Provisioning Server 5.1.
  • XenApp 5.0, Platinum Edition.
  • Windows Vista Business (x86)
  • 300 Users, all will use XenDesktop for OS and XenApp for Application Delivery.
  • Endpoints are XP Embedded Thin Clients.
  • Single Location, Single Data Center.
  • Users occasionally want to access the environment from home.
  • Users are “Task Workers”

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.


Making Changes to a vDisk in XenDesktop & Provisioning Server

I’m often asked how to update a vDisk for use with XenDesktop, so I figured I should publish my answer.

1. Navigate to your store via Windows Explorer, Copy the .VHD file currently in use, then Paste it.

2. Rename it – We use A,B,C,D and rotate each time we update.

3. Open the PvS Console, Navigate to your vDisk Pool.

4. Right Click on vDisk Pool, Select Add Existing vDisk.

5. Make sure your Store and Server are correct, then click Search.

6. Select the new vDisk and click Add then Close.

7. Open your vDisk Pool in the PvS Console.

8. Right Click on the new vDisk, click Properties.

9. Click Edit file properties…

10. Change the Access Mode to Private Image and adjust your revision numbering.

For the next steps, I use a VM that is exactly like the VMs the image will be used on. This method is documented in the XD Getting Started Guide and is referred to as BaseDesktop1.

11. Expand Device Collections.

12. Assign your BaseDesktop1 (or whatever you’ve named it) the new vDisk that is in Private Mode.

13. Boot the VM in your Hosting Infrastructure of choice.

14. Make Changes.

15. Shut Down VM.

16. Change the vDisk to Standard Mode.

17. Assign vDisk to whichever VMs you wish.

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.