by: Helge, published: Nov 20, 2013, updated: Dec 5, 2013, in

Persistent VDI in the Real World – Architecture

This is the first article in a multi-part series about building and maintaining an inexpensive scalable platform for VDI in enterprise environments.

Requirements

Before we can even start to think about a possible architecture, we need requirements. Only requirements enable us to make choices that benefit the customer. Without proper requirements we are not building for the real world but for some alternate reality. Please keep in mind when reading this article that the solution presented here only makes sense for you if your requirements are similar.

These are the requirements we need to work with:

  • The customer wants to virtualize desktop PC workloads typically found in larger enterprises.
  • VDI is not going to be the only platform. Citrix XenApp is and will be the most important platform. Additionally there will be laptops and potentially desktop PCs.
  • Operations/management costs should be kept at a reasonable level.
  • Hardware costs should be kept low, but servers need to be bought from the preferred supplier, which is HP.
  • Availability should be similar to traditional desktop PCs.
  • Performance should not be worse than with the current three year old desktop PCs.

Choosing a Broker

With Citrix XenApp already in use today and even more so in the future, it makes a lot of sense to choose XenDesktop as the broker for VDI. Today’s deployments benefit from combined licensing infrastructure and user-facing components (client, web portal, remote access). Tomorrow’s installations will come even closer together due to the face that XenApp’s IMA architecture has been swapped out for XenDesktop’s FMA in XenDesktop 7.x and XenApp becoming a part of XenDesktop (called “App Edition”).

Pooled or Persistent?

The answer to this is already in the title, so I am going to keep this section short. Let me just say that there are very few use cases where pooled VDI makes sense in organizations that have already deployed server-based computing (SBC). Either give users a stateless desktop on a terminal server where only individual settings are retained but the system configuration cannot be changed or give them a machine that keeps any changes in between logons. If you choose the latter, do not simulate persistence by adding tools like Citrix Personal vDisk to a pooled desktop: this only increases the complexity and makes the resulting system much more difficult to maintain. Go for full persistence instead, where there is one VM per user without any differencing or secondary disks. You will be rewarded by having an architecture that is simple, stable, well understood and can be managed by the myriad of PC management tools out there.

32-Bit or 64-Bit?

An article on the Citrix Blogs discussed this and recommended to use the 32-bit version of Windows 7 with VDI. I must say it left me speechless. Why anyone would not go for the 64-bit version of Windows is beyond me. Luckily most people seem to agree with me. From my experience these are the killer arguments for x64:

  1. One platform for laptops and VDI: you are not using 32-bit for your fat clients, are you? And, trust me: you do not want to manage VDI differently, just because it is virtual. A PC is a PC.
  2. Flexibility: This is the major advantage a virtual desktop has over a physical PC (no, price is not). Being able to add RAM to a machine when the workload requires it is an important part of that flexibility. With 32-bit you are throwing this advantage away since it caps the usable amount of RAM at approximately 3.5 GB.

Conclusion of Part 1

Given the requirements listed above, it makes a lot of sense to complement XenApp with XenDesktop. Since there is already a stateless platform in place that suits simpler use cases very well (XenApp), we build XenDesktop in such a way that it is able to fully replace a desktop PC by making it persistent. In order to leverage all the advantages VDI has to offer we install the 64-bit version of Windows.

In the next installment of this series I will explain how to solve the storage problem. Stay tuned!

Previous Article Workaround: "554 rejected due to spam content" sending e-mail
Next Article Monitoring any Application's Startup Duration with uberAgent 1.6