The team at Helient Systems has implemented a lot of VDI, but this multi-part case study illustrates our continued commitment to innovation within this arena. Embracing new and improved capabilities of Citrix XenDesktop to provide persistent storage for users, we were able to successfully close the gap between the physical and virtual desktop user experience.

Taking VDI from Good to Great, Part 1

Helient recently completed a legal desktop project which effectively highlights the significant strides we have made in taking VDI from “good enough” to a true Tier 1 replacement for the physical desktop PC. The main objective of the project was to migrate the firm’s 300 users from a legacy Citrix Presentation Server farm to a Windows 7 & Office 2010 VDI desktop with updated versions of all applications where possible. The firm also wanted to improve performance, stability, application management and the overall user experience.

Helient Systems felt that with this project we could chart new territory in terms of the user experience offered by a VDI solution. We explained to the firm why VDI has historically been deployed with some deliberate limitations on functionality. This has been done for a number of reasons, both technical and operational in nature. However, new developments in the marketplace presented an opportunity to close the gap between VDI and physical PC functionality and performance. With the approval of the firm we embarked on a plan to push the envelope and strive to advance the state of the art as follows:

1. Reduce login times to be on par with physical desktops
2. Employ Outlook cache mode for suitably-sized mailboxes
3. Provide native Windows 7 indexing and search
4. Allow “user installed applications” when warranted
5. Deliver high frame rate, high definition audio and video

Putting Persistence Back on the Table

The first 4 items on our target list are very closely related, and in order to deliver on them we were going to need 2 things: a persistent VDI desktop for every user, and very fast storage. Before we get into why persistence is a requirement, let’s first discuss whether it is even a viable option.

Historically, we have always implemented a non-persistent desktop model in legal VDI projects. The primary rationale for this has been as follows:

• Persistent virtual desktops would require full software lifecycle management just as physical PCs do, essentially just “moving” the problem of desktop management from the desk to the datacenter.
• Persistent desktop configurations would immediately deviate from one another and no longer offer the benefit of a single, or very few, standard images to manage.
• Persistent desktops will not revert back to the pristine state of the master image upon reboot, thus becoming susceptible to viruses, malware, and software corruption.
• Persistent desktops would require ever increasing amounts of storage and IOPS over their lifespan to store the deviations from the master image.
• Legal desktops are highly standardized anyway, and locked down environments have been accepted by the user community, so there is not a real need for persistent customization.

Figure 1: Disk composition in non-persistent VDI. Base disk is read-only and Diff disk is deleted on restart.

These remain very important and legitimate points, however a new feature in Citrix XenDesktop and recent reductions in the cost of SAN arrays incorporating very fast solid-state disk suggested we should revisit these old tenets of VDI best practice to see if they still apply.

Personal vDisk, or PvD, a new feature in XenDesktop 5.6, provides a dedicated, persistent storage area for each virtual desktop. This storage area is intended to contain user specific data and applications, allowing persistent personalization. But, unlike previously available methods of providing persistent user data, PvD introduced some important benefits:

1. Future changes made to the master desktop image can be copied to the entire collection of existing persistent desktops, so that each does not require individual software management.
2. A user’s personalized desktop can be “reset” back to its original, unused state very quickly and easily in response to any security or operability issues.

These two advancements effectively cover the prevailing operational objections to persistent desktops, but what about the storage and IOPS issue? Here too, PvD has some distinct advantages:

1. The storage for the persistent data (PvD) can be separated from the storage for base image and the non-persistent, or differential, data.
2. The user’s PvD can be limited to a specific size, monitored for usage, and individually resized as needed.

The first item allows deliberate targeting of the storage that is best suited for each role. We can use SAS disk for the frequent, small random writes of PvD, and SSD for the large sequential reads of the master image and non-persistent cache disk for rapid boot storm processing and application launch. The second allows us to put strict controls on how much space is consumed by the users’ customizations and data, allowing proper management of SAN capacity. When combined with attractively priced enterprise level SSD, these new features in XenDesktop truly make a persistent desktop a realistic option.

Figure 2: Disk composition in persistent VDI with Personal vDisk. PvD retains user apps & data across restarts

So, How Does Persistent Storage and a Dedicated Desktop Help?

Basically, the only reason we have historically had limitations around items 1-4 in our design objectives list is that all of these features expect changes made by the user, or by the system on behalf of the user, to be “sticky.” Oh, and each is also capable of wreaking havoc on disk IO and absolutely killing VDI performance when it is not sticky. Let’s take a look at why that is.

When a user first launches Outlook in cache mode, Outlook creates a data file on the local disk and begins synchronizing the user’s mailbox to this file. The file is roughly 20% larger than the user’s Exchange mailbox, cannot be moved to the network, and can take a very long time to download from Exchange, especially when dealing with the multi-gigabyte mailboxes common in a law firm. In a non-persistent model, this file would get created over and over again, every time the user logs out and logs into a different VDI desktop in the pool. While nothing prevents us from enabling cache mode in non-persistent VDI, it is an absurdly bad idea and would be completely unusable as every user recreates this file every time they login. If you consider the morning login storm this would create, the issue with this should become clear. And this scenario becomes even more untenable when you consider the next objective, Windows Search.

Similar to Outlook, Windows Search creates a data file on each user’s disk, in this case containing an index of all the content in the user’s mailbox and standard content storage areas (My Documents, etc.) Unlike Outlook’s cache file, the index file itself is not very large (about 10-15% of the user’s mailbox size,) but the process to create the file is extraordinarily CPU, memory, and IO intensive as it “crawls” through all messages, attachments, contacts, calendar items, tasks and documents and builds the search index. And, yes, with a non-persistent desktop this process too would have to run every time the user logs out and logs back in. So, even with tens of thousands of IOPS available, the indexing process, when combined with Outlook cache mode initialization, is the one-two punch that renders them both unusable in a non-persistent desktop.

“I’ve written again and again that for VDI to really succeed, we have to be able to deliver persistent desktops. While that’s been theoretically possible since 2006, it’s always been very expensive.”

– Brian Madden, BrianMadden.com, March 18, 2013

Probably the biggest, most common complaint we have heard about VDI has to do with login time. And the biggest contributor to slow login time in most cases is loading the user profile from the network. Even with a perfectly dialed-in profile management solution and properly redirected folders, a non-persistent desktop has to load at least a portion of the user’s profile from the network at every login. While the streaming feature of Citrix Profile Management can greatly reduce the amount of data loaded from the network, the best case tends to hover around a minute for login. Here, too, providing persistent storage makes all the difference. Loading a locally cached profile at login is exactly what a physical PC does, so we can expect to get the same, snappy performance out of a VDI session login, bringing login times down by at least 50%.

The final missing element in non-persistent VDI has to do with per-user or per-group application installs. Historically, we have had two practical options for delivering applications in VDI:

1. Install the application into the master image, aka “baked in” applications
2. Publish the application from XenApp

While there are some other options we won’t get into, such as application virtualization & streaming, these are the two that are not overly complex to manage and are best suited to most environments especially given that most firms who use VDI are also entitled to XenApp.

Personal vDisk, however, opens up a new possibility: install the application into the user or group’s VDI desktops. Since every user has a persistent desktop, their application payload can be customized to their needs. The firm can choose to manually install the needed applications or employ Enterprise Software Management tools such as SCCM to deliver the required apps automatically. This latter option is preferred, especially if there are more than a few one-off applications that need to be delivered.

Give Me Video or Give Me Death!

The final shortcoming of many desktop virtualization projects stems from the evolution of web-based animation and video from a novelty to an absolute requirement. Virtually every web site now makes extensive use of Flash or HTML5 video & animation. Online video has legitimate business purposes for training and research. If HD video does not perform well in a virtual desktop environment, it will be noticed, and it will cause dissatisfaction and inhibit user acceptance.

To address this requirement, we first needed to make sure that the relevant Citrix HDX enhancements were enabled through policy to redirect multimedia to the endpoint. This leverages the local graphics processing power of the endpoint to render multimedia and then composites the rendered content with the Citrix display stream. We also needed to make sure the endpoints had the latest Citrix Receiver and Adobe Flash Plug-in software installed and properly configured. Finally, we had to make sure the endpoints had adequate video processing capabilities and access to the Internet so that video streams could be fetched and rendered at acceptable frame rates directly on the user’s device.

Sounds like a Plan

Now that we had a plan to address all of the firm’s requirements, we could begin the work of building out the infrastructure and the VDI environment, knowing that we should be able to deliver an amazing experience. But before we went too far, we needed to validate our assumptions about these new capabilities and determine how they would scale across hundreds of virtual desktops. For this, we would employ a remarkable load testing tool called Login VSI to simulate the workload of 300 simultaneous users.

But that is another story which will be the subject of part 2, coming soon!