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:

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.

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.

One Response to Persistent VDI in the Real World – Architecture

Choosing x64 over x86 without properly considering application and device compatibility has been a problem for some time now. I wanted to explain the advantages and disadvantages of each option, I’m definitely not providing a blanked statement that x86 should always be chosen.

As I wrote in response to a comment –

“I want to encourage people to carefully consider the pros and cons of 64-bit computing before taking the plunge. My concern is that too many desktop virtualization projects go 64-bit without planning for 16-bit apps.

With sufficient time and the right tools you’re right – this is a great time to make the switch. AppDNA is excellent at finding 16-bit code and we have some great options for delivering them to 64-bit desktops. Right now though, I consider 32-bit to be the safer option because there are far more 16-bit applications than 64-bit ones.

The good news is that we don’t have any immediate pressure to make the switch. Microsoft has released a 32-bit version of Windows 8.”