Pieces and parts
To picture how Citrix XenDesktop works, you need to understand the various components. Obviously, there's a hypervisor that handles the VMs themselves. Citrix XenDesktop is built around XenServer, but can play with VMware VI3 as well as Microsoft's Hyper-V. Then there are the management tools, provided by XenDesktop Provisioning Server and XenDesktop Desktop Delivery Controller.
The Provisioning Server is a major component within XenDesktop. It serves as the central proxy for all desktop VM vdisks (virtual disks) and allows administrators to build, configure, and manage all the desktop VMs. The wizard-based approach to building and managing those VMs is well appointed, and handles nearly everything fairly seamlessly. Building large groups of VMs is simple: Create a "gold" VM disk that contains the OS, all supporting applications, and settings, and is joined to an Active Directory domain, and then create a VM template that sets the RAM requirements, I/O devices, and so forth. Once that's done, you can easily create one or more VMs from that image to be served to users as desktops. In this way, it takes no more time to create 20 VMs than it does to create a single VM.
The Provisioning Server is also the key to managing all the write caching that occurs during user sessions. Write caching is an important aspect of Citrix's VDI infrastructure. When a user logs into a session on a VM, changes made to the OS itself are not written to the VM, but to a write cache that lives on a shared LUN or other shared storage medium. This allows the user to make changes that are not retained when the VM is rebooted. This maintains the integrity of the VM and is also helpful in reducing the chances of malware infiltrating the infrastructure. If something is amiss, simply reboot the VM to a known-good state. The Provisioning Server is relatively smart, and is capable of not only provisioning new desktop VMs but also adding them to the AD domain on the fly.
Citrix estimates that a single physical Provisioning Server can handle between 350 and 500 simultaneous XenDesktop users.
The Desktop Delivery Controller is just like it sounds -- it manages user access to desktop VMs. Pools of desktops can be defined and linked to specific Active Directory groups. In this way, you could give all HR users a desktop VM with 512MB of RAM and a specific CPU share, while all Engineering users get a desktop with 1,024MB of RAM and a more powerful CPU. Obviously, you could also deliver Windows XP to one group and Vista to another.
The DDC is also where time-based resource management is handled. It's possible to create rules that will keep a minimum number of desktop VMs ready and waiting for a login between 8:30 a.m. and 9:30 a.m., and then reduce the number of idle VMs throughout the rest of the day, finally keeping a small number active after business hours. This reduces the load on the VM infrastructure and helps handle the morning ramp-up. It's also possible to assign desktop VMs to specific users, rather than pooling them for a group of users.
Sign up for Computerworld eNewsletters.