October 18, 2011 | Written by: Andreas Groth
Share this post:
Parts 1 – 5 are also posted at Virtualization Matrix.
In this series of blogs, I’ll share my experience as IBM practitioner – simply based on recent client engagements where desktop virtualization, private desktop cloud, and desktop as a service (DaaS) were target environments (I will collectively refer to it as virtual desktop infrastructure, or VDI”). It is therefore a reflection of what customers actually implement, mixed with my comments and evaluations.
In particular I discuss the following aspects:
- Software Stack – or – “Is there a common software stack for VDI in the industry today?”
- Advanced Graphics – or – “I need advanced graphics, what shall I do, is it always out of scope?”
(Looking for an “at a glance” view of advanced graphics capability by vendor? Then, read on.)
- Cost – or – “I can’t get to a viable price point for my VDI environment, what am I doing wrong?”
- Future/Vision – or – “Is VDI for me? How will recent announcements impact the future of VDI?”
1.1 Observed patterns
Although I’ve been involved with desktop virtualization for several years, this article was triggered by the emergence of a “pattern” in my VDI projects over the last year (based on field experience, not some nebulous industry projections).
These patterns are currently common across customer from various vertical backgrounds – although a large segment of my recent engagements has been with European system integrators and customers in the financial sector, typically of larger size with targeted environments of 2,000 seats up to 100,000 seats.
Most of those already had an existing proof of concept (POC), pilot, or smaller production environment in place and considered moving to “their phase 2.” Phase 2 typically involves a larger production user base (greater than 500 seats), often aiming to include more demanding user categories (power users and higher graphics requirements) and distributed environments (that is, branch offices).
…I hope we all agree that we’d be pretty poor architects/consultants if HVD was our only answer to every desktop infrastructure scenario…
This article is mainly restricted to VDI (hosted virtual desktop (HVD) based architectures). However, I hope we all agree we’d be pretty poor architects/consultants if HVD was our only answer to every desktop infrastructure scenario, but please allow me to leave it at that.
I started writing this article just before I made my way over to VMworld Las Vegas and some of the announcements and discussion (including a particular enlightening one with Massimo Re Ferre from it20.info ) changed some of the dynamics in this space so I’ve added “Real-World VDI (Part 4): Rethinking my view of VMware’s user capabilities – the impact of VMware’s recent announcements.”
But let me first share my thoughts as originally intended, which will also make the significance of the recent announcements clearer.
Let’s start with the software stack.
1.2 The status quo of VDI software stack: VMware or Citrix?
OK, I admit, this can be seen as a dubious title for many reasons. Is there really a status quo (and can there realistically be one), why restricting it to VDI and what about the other players in the game? And that’s exactly the point; it’s often not a clear-cut single vendor stack we see implemented.
So the question I typically get is “Am I the only one with this odd software stack, there are just too many combinations of products from different vendors – what are others (in my industry) using?”
The majority of customers asking me this question actually then go on to describe a very similar (multi-vendor) stack – including the last three large customers in a row … and that stack was:
L1 (Hypervisor and hypervisor management): VMware vSphere
L2 (Broker/Session Management): Citrix XenDesktop
L3 (Application Virtualization): Microsoft App-V
L4 (Profile Management): Sometimes a combination of roaming profiles and folder redirection, sometimes a pilot to implement AppSense, or sometimes they have both concurrently.
As you can imagine, I am simplifying the layers in the interest of time, and again, I am not making any claims that this is an objective representation of all customer segments, sizes and regions by any means. I will cover other solution like Virtual Bridges Verde in a future post. Verde is an extremely interesting solution that manages to combine simplicity with impressive capability (including client hypervisor, branch office solution and good (SPICE-based) graphics capability. And, if you are running Linux desktops, then this solution is one of the best out there (and you can trust me that I am not just saying that because of IBM reselling the solution.)
So back to the stack, affinity typically decreases with the higher layers, so for instance, app-virtualization and profile management are less likely to be nailed down. Also, before I attract the wrath of VMware View fans, I am not making a general stack recommendation here. The purpose of this article is to convey what customers decided to implement after careful consideration.
(Also, be sure to check out “Real-World VDI (Part 4): Rethinking my view of VMware’s user capabilities – the impact of VMware’s recent announcements”)
1.2.1 Hypervisor: ESX
A pretty obvious choice you can argue, ESX is the most mature, feature-rich hypervisor in the market.
Often this choice is simply an evolution of what has been done in for server virtualization (rather than based on specific evaluation of suitability for VDI); existing skill set, license agreements, confidence and relationships often make ESX the natural choice.
Many clients confirmed that they are actively evaluating hypervisor alternatives for VDI attempting to reduce cost.
Most clients, however, confirmed that they are actively evaluating alternative hypervisors, attempting to reduce cost (with, for example, XenServer but actually increasingly Hyper-V), with one large client actually stating that the directive given by their management is Hyper-V, “whether they liked it or not,” because of existing licensing agreements with Microsoft.
The SP1 addition of Dynamic Memory helped, and RemoteFX has the potential to address some of the graphics requirements; however missing NAS support (except CIFS) for Hyper-V and the upcoming release of SCVMM 2012/Windows 8 (which many see as first credible competitor to vSphere) seems to be holding back actual adoption of Hyper-V as platform for VDI.
Comment: Microsfot just announced that full NAS support will be part of Hyper-V3 (Windows Server 8).
XenServer is considered when a single (Citrix) vendor stack is preferred (support, integration, skill set), and features such as IntelliCache and GPU pass-through are hypervisor-specific considerations that customers take seriously (such as RemoteFX for Hyper-V).
We (IBM) have always advocated customer choice when it comes to virtual platform selection so we clearly support this “best of breed approach” where it makes sense.
1.2.2 “Broker”: XenDesktop
A multitude of “connection broker” technologies are on the market (Quest vWorkspace, Leostream, Virtual Bridges Verde, and others) with varying capabilities and scope (session management, deployment, and so on). There were endless discussions and many points raised but when asking the clients “what’s the main reason for picking XenDesktop” the common points were:
The “Flexcast” concept Citrix promotes and the technologies it provides to enable this “one does not fit all” approach resonates well with clients.
The “Flexcast” concept Citrix promotes and the technologies it provides to enable this “one does NOT fit all” approach resonates well with clients. The fact that Citrix can not only get VDI and streamed applications but also hosted shared servers (also known as presentation server, terminal server, XenApp) from the same vendor alongside various network appliances for delivery optimization seems to play an important role alongside the fact that Citrix receiver promises connectivity from “any” device.
The overall value proposition of these capabilities made XenDesktop the product of choice.
1.2.3 Application virtualization: Microsoft App-V
Let’s not get into a definition of app virtualization (because there are different models), but here I am referring to the ability to sequence an application, deliver it to the end-point (for example, stream it to a virtual desktop), and have it run in an encapsulated runtime environment “bubble” with the usual advantages of portability and isolation.
Many vendors provide solutions in that space (VMware with ThinApp, Citrix – XenApp, Symantec SWS, and others).
From my experience app virtualization in “phase 1” is often not fully explored. One of the biggest drivers for app virtualization is the goal to deliver stateless desktops, but in many case, reality prevents the use of 100 percent stateless instances in larger environments, whether for technical reasons (for example, typically not all apps can be virtualized) or organizational (user insisting on locally installed apps). However, some administrators I worked with even started to virtualize and stream apps to physical endpoints before looking to virtualize the desktop itself..
Technologically, ThinApp has the advantage that it runs in “user-mode,” which in simple terms means that the app is less likely to affect other processes in case of failures; it is also using an agentless approach – generally favored to avoid yet another update and certification point. But, at the same time it is this agentless model which makes it less integrated into the central management environment.
Administrators were pretty consistently telling me that the level of integration and central management of application virtualization makes them pick one solution over another.
Administrators were pretty consistently telling me that it is this integration and central management that makes them pick one solution over another (on a very practical level), and currently favor App-V over ThinApp even though some improvements have been made with basic integration in recent VMware View releases.
Although XenApp is clearly used in many accounts for server-based computing (also known as terminal services), I have seen only relatively limited use for app streaming in multi-vendor “best of breed” environments.
Because of the emerging nature of app virtualization, however, the affinity to a product or vendor in accounts is here less strong than for example with the hypervisor or broker – often still more a vision than final choice in phase 1, but in phase 2 it is typically recognized as a required enabler for (cost) efficient VDI environments using stateless images.
Ruben Spruijt from PQR has created a white paper Application Virtualization Smackdown covering this topic in great detail. It is definitely worth a read if you are exploring this area.
1.2.4 Profile management: Roaming profiles, AppSense
Arguably the least defined and therefore potentially most complex aspect of desktop virtualization (not just HVD) is the profile management.
It is least defined because products have evolved from initially addressing the “user profile” issues, to include an ever increasing scope of “user environment management” (UEM).
User environment management is undoubtedly the component virtualization architects who have grown from server virtualization to desktop virtualization typically struggle with most.
It’s also undoubtedly the component virtualization architects who have grown from server virtualization to desktop virtualization (like me) typically struggle with most. When I first worked with AppSense years ago I was dazzled by the capability but also repelled by the complexity of user management in general – something desktop administrators have no issues with.
In simplified terms, the UEM goal is to achieve a consistent user experience across images and devices, reduce login times, and address consistency issues with classic Windows user profiles. However, products like AppSense or RES provide capabilities far beyond that by including aspects of resource, security, license management and reporting capabilities.
Out of the last four larger engagements, three initially used Windows roaming user profiles and were at varying stages of piloting AppSense (one also considered RES). One client stated that they were not going to investigate or use another approach anytime soon (and stayed with roaming profiles and folder redirection).
In my view, there is no easy answer or recommendation without deeper analysis, and a generalization is dangerous, so let me be clear – although there is no doubt that you will need to address the issue of user environment “mobility,” it is a very individual technology decision that will require you to invest in piloting the approaches and determine what scope you want it to address.
OK, that was the software stack; so what about the Achilles’ heel of HVD…high-end graphics?
See “Real-World VDI (Part 2): Advanced graphics requirement – DirectX and OpenGL with HDX, RemoteFX, and PCoIP.”