VDI for me. Part 1


It doesn’t take long for those in IT to see the letters “VDI” show up on the radar.  Maybe a morning digest of RSS or twitter feeds might be all it takes.  But the subject of Desktop Virtualization can be a difficult puzzle to piece together if you haven’t already invested in it.  There is a lot to sort through, even if you are contemplating just a small pilot project.  VDI deployments can be a highly visible IT project (in user expectations, experiences, and financial commitment), so if you are contemplating a pilot project, you’ll want to stack the odds of success in your favor, and make that first impression a good one.  As I embarked on my own VDI project, I noticed that while there was much to be found on the net regarding VDI in general, one thing seemed remarkably absent; information on how pilot projects are approached, and actually deployed.  My posts won’t be dissecting any CAPEX or OPEX numbers, nor will it attempt to prove that VDI is the perfect solution for every scenario.  But rather, I want to give you a glimpse to what a VDI pilot project actually looks like. 

As I mentioned on previous posts, my recent efforts to upgrade my hypervisor to vSphere 5 was for one real purpose.  I wanted to deploy a Proof of Concept (PoC) for VDI in our environment using VMware View 5.  The company I work for makes industry leading data visualization and simulation analytics software.  Our customers, who are often scientists and engineers, need to understand simulation results to make smart design decisions.  The software is typically installed on a user’s local workstation (Windows, Linux, Mac, or Unix) and interacts with data that is either on the network, or if performance dictates, their local system.  The nature of the problems that are trying to be solved, along with our software, can demand high computational horsepower with high-end graphics.  Many in the CAE/CAD industries are familiar with the demands of the local workstation performing the work.  But there are some scenarios with VDI that make it quite compelling that are not brought up very often.  We wanted to understand those benefits better.

Much of the interest internally transpired from a technology lunch-and-learn session I gave to our staff.  My motives for doing such a thing were two-fold.  1.)  I wanted everyone interested (not just key stakeholders, but software developers, technical support, etc.) to be aware of some things I knew they weren’t aware of, and 2.), I thought it would be fun.  I covered anything from how virtualization has changed the Datacenter, to demonstrating how common assumptions about our own internal systems, as well as our customers, may be highly misguided based off of new technologies.  While the focus was the Datacenter, I translated much of that into how these changed might affect end users.  It was a tremendous success, and even required an encore presentation for those who missed it.  This piqued the interest of the key stakeholders, as they understood it could have a significant impact on our product roadmap.  Combine this with the impressive “technology previews” of things like “AppBlast” and “Octopus” at the 2011 VMworld, as well as recent partnerships announced by VMware and NVIDIA for providing hardware based GPU acceleration to hypervisors, and we had something we needed to look into.

Due to the type of software we make, we had some unique use cases that we not only wanted to understand better ourselves, but perhaps provide our customers with solutions on a better way to do things.  I had several objectives I wanted to achieve.

  • Understand how we could improve on our own internal efficiencies and toolset to our staff.  We have taken a fairly aggressive approach already to provide ubiquitous access to everyone in our office (tablets for everyone, and their use encouraged in meetings, etc.).  We also have a great team of software developers on another continent, and are always looking for new ways to integrate them with our systems.  We needed to look at tools that not only help that, but help mitigate the the operational expenses and security challenges of traditional workstations to end users.  These seem to be the mostly common reasons cited when organizations are looking into VDI.
  • Demonstrate to our customers possibly “a better way” to work.  Believe it or not, many consumers of applications that have large data still either download the data locally, then work on it, or rely on local high speed networks to transmit the data.  What happens if the data, and the system used to present the data lived in the Datacenter?  These days, under a virtualized infrastructure, network communications may never even see an Ethernet cable or a physical switch, and the results can be impressive.  This is the benefit that most of us have enjoyed while virtualizing our server infrastructure.  So if the new type of client server arrangement only had to deal with transmitting screen data, then a world of possibilities opens up.
  • Demonstrate our software.  We rely heavily on feedback from new and existing customers on our products, and we need them to try our software.  If your customer base runs on extremely sensitive or secure networks, you’ll find that a pattern emerges.  They won’t let you install trial or pre-release software on any of their machines.  We’ve resorted to some pretty crude methods to help them test our software (shipping some old laptops), but obviously, this doesn’t scale well, and frankly, doesn’t give a good impression for a company who strives for innovation.  
  • Understand new display protocols, and how this could impact how datacenters are constructed.  Remote displays are a big concern in the visualization, CAE, and CAD worlds.  Years of dealing with various display protocols have resulted in similar experiences.  Most share the trait of using connection oriented protocols to transmit rendering instructions.  They tend to suffer on connections beyond the LAN that may have high latency and packet loss.  There are new approaches to help change this.

GPUs, Remote Displays, and Client Server
Most heavy hitting graphics software packages have historically relied HEAVILY on GPU power provided by a real video card.  This has been under the assumption that they’d always be there, and that GPUs are incredibly powerful.  Well, as you can imagine, that doesn’t play to the strengths of traditional virtualization, where video has barely been an afterthought (at least so far).  Not a big deal when you were virtualizing your server infrastructure, but a pretty big deal when you are trying to virtualized desktops.  Task workers may never notice the difference, but users of high end graphics will.

Remote display protocols come in a variety of forms.  Some are definitely better than others, but most suffer from fundamental issues of being based on TCP.  The rules of TCP guarantee reliable and orderly delivery of packets to be reassembled at the target.  Network communication wouldn’t have gotten very far if it didn’t have a way to guarantee delivery, and while this is great for most things, it doesn’t shine when it comes to video, animations, or high speed screen refreshes.

So why would a software company be so curious about this new set of technologies? Technologies that for the most part, we have no control of?  The answer is that it can change how one architects software. For example:

  • Sometimes there are calls for a true two-piece, client server software, where the client application and the server application are working together to perform their own dedicated tasks, but in different locations.  The goal with this type of client server arrangement was to use recourses as efficiently as possible. It is not as common as it once was, and history has demonstrated that this approach can be complex, wrought with problems, and very expensive to develop and maintain, especially when dealing with heterogeneous environments.  It may work in some environments, but not in others.  It may or may not use chatty protocols that simply don’t work well over poor network conditions. The further the two are separated, the more you introduce issues.  Firewalls, network traversal, etc. all complicate matters.
  • The other form of client server that people are most familiar with is where the application and computing power is in one location (e.g. The desktop) while the files being accessed are on a file server.  While it is very clear what is doing the work, it begins to falter with large data, or traversing geographic boundaries.  Look at the traffic generated by opening up a modest sized spreadsheet over a VPN connection, and you’ll see what I’m talking about.

With the trends on virtualizing infrastructures, the datacenters have collapsed to be more centrally located. If the client system (a workstation, or in this case, a VM) is now in the same virtual space as where the data lives (the server, or in this case, a VM), it can have an impact on application design.  Instead of using “client rendering” the model uses “on-host” rendering, where all of the heavy lifting is performed inside the Datacenter. Meanwhile, the endpoint devices, such as laptops, tablets, zero or thin clients, which do not need to have much horsepower, are really just acting in a presentation type role. It’s a bit like wondering how much CPU power your TV has.  Answer… It doesn’t matter, as the score of the baseball game is being rendered on-host.

The Plan
I wanted to make sure that I wasn’t claiming that VDI will change everything, and that every single person will be working off of a zero client in 12 months.  Nor was I suggesting that running a virtual desktop on a tablet is the ideal interface for interacting with a desktop.  That wasn’t my point.  It is ultimately how applications are delivered to the end user.  I wanted to help everyone understand that for the majority of our customers, they simply work on the systems that are provided to them by their IT Department.  Rarely does an end user get line-item-veto power on what they use for a computer, and since we know IT infrastructures are changing, the evidence suggests that what the customers will be using is going to change as well.  In fact, there is pretty good likelihood that we will have a customer who shows up one day to their office with nothing more than a zero client in front of them.

The idea behind the PoC was to invest a minimum amount to provide as much information possible to make smart decisions in the future.  In that spirit, I also plan on revealing results on these posts along the way as well.  I knew my initial project wasn’t going to include the time to look into every feature of a fully deployed VDI.  I was going to stick to the basics, and see how they work.

  • Test access to VM’s using VMware View as the connection broker (via PCoIP, and RDP)
  • Test access to high end physical workstations with VMware View as the connection broker. (via PCoIP, and RDP)
  • Test these systems from a variety of endpoints.  From existing PC’s, to zero clients, to Linux desktops and Mac clients, to wireless tablet devices and smart phones.
  • Test these systems from a variety of connection scenarios.  A connection to something on the LAN is very different than something on another continent. 

Bullet number 2 may have caught your eye.  Creating a unified remote display experience isn’t limited to just virtual machines.  With the power of PCoIP, and using VMware View as a connection broker, one can house high end workstations IN the Datacenter.  They would be a 1:1 assignment (1 active user to 1 workstation) like a traditional workstation, but they’d be close to the storage (perhaps even directly connected to the SAN if desired), and offer the full GPU capabilities of the workstation.  Access to them would be no different than if they were VMs.  In fact, the end user may never know if it is physical, or virtual.  It’s a provocative thought for users of CAD, solid modeling, or simulation analytics software.

Components of my Pilot Project

  • VDI software.  VMware View 5 Premier (their 10 client “starter pack”) running on vSphere 5.0 infrastructure.  This would offer the abilities of the connection broker, the variety of connection protocols (PCoIP, and RDP) among other features.
  • Back-end storage.  For our small pilot project, this was limited to our existing Dell EqualLogic SAN arrays.  They would be fine for this small pilot.  However, I have no illusions about the storage I/O requirements of VDI at a larger scale, and hope that if things go well, a super-fast EqualLogic hybrid SSD/SAS array is in our future.  More on the subject matter of storage and it’s importance to the success of VDI in future posts.
  • Firewalls.  Not to be overlooked, this plays a significant role in how you can present, and secure content.  I have the good fortune to be working with what I believe to be the best of breed.  Microsoft Forefront Threat Management Gateway (TMG) 2010 running on a Celestix MSA appliance.  (more on this in future posts)
  • HTML5 presenter.  While View 5 doesn’t natively support HTML5, I wanted to see what this was like.  Not only would give aid the ability to evaluate our software, but give our developers some insight on how HTML5 may play a part in virtualized, application delivery. (e.g. AppBlast.  Gee, can you tell I’m antsy to get me hands on this?) For this experiment, I’ll be using Ericom’s Access Now for VMware View.
  • Zero Client.  For this, I will be using a Wyse P20.
  • PCoIP host card.  This is an eVGA HD02 PCoIP host card installed on a higher end workstation I will be using to performance against a high end workstation sitting remotely in the Datacenter, and brokered by VMware View.
  • My Primary Site, and my Colocation site.  The CoLo site is not used for anything other than where my offsite SAN replicas go to. My plan is to change that.  Long term intentions are to house services that are more appropriate for that location, while in the near term, I will be housing part of my VDI pilot there.

Early lessons learned
If you are reading this post, more than likely you are well entrenched in the world of virtualization.  Never underestimate that the lack of knowledge in this arena by your coworkers or stakeholders.  About 3 years ago, I started giving a monthly IT review to everyone in our company on what is going on in IT.  This helps dispel the myths behind the giant IT curtain, and possible gives some insight as to the complexities of modern environments.  But no matter how much information I provide, I’m constantly challenged by these technologies, with the occasional question of, “now who is VMware, and what do they do?”  or “What’s a SAN?"  Be prepared to repeat your message several times over.

I would also emphasize VDI as not being an either/or scenario.  It is another form of a computing environment that provides unique capabilities to deliver applications and content.  We know that there are many vehicles for this already, and it continues to evolve.  So in other words, no need to make bold claims about VDI.  This also keeps you out of the business of predicting the future – not a favorable occupation in my book. 

As you have the opportunity to have users try out various use cases, you may have to throttle any over exuberance on the user’s behalf.  Large deployments are different than pilots.  The end user may see the brilliance of the solution, while the budget line owners see nothing but the large capital investment. 

Coming up
In upcoming posts, I’ll share how I chose to design a pilot VDI arrangement for our testing internally, externally, and how we plan to use it for our own internal needs, as well as our customers.  I have no idea how many parts this series is going to be, so bear with me.  What I hope to do is to give you a better understanding of a VDI pilot project in the real world, providing enough detail to be helpful with your own planning.

The VMware, NVIDIA Partnership announcement

Planning for VDI has little to do with the Desktop

VMware vSphere 4.1 Networking Performance