Understanding Where VDI Fits in the Enterprise
With the release of Windows Server 2008 R2, Microsoft is now in the VDI game, although quite frankly I’ve sat through sales pitches by VMware reps talking about how VDI is the “way to go” for the future of desktops and I don’t quite see it that way. Our past year of experience implementing VDI has proven that VDI has an excellent value proposition for organizations, but it’s not the end all of desktops, it’s just one alternative…
This article (2 parts) will talk about our experiences with VDI, where it fits, and I’ll dig into specifically HOW to get VDI to really work in the enterprise (which sadly to say, I haven’t found any good guides out there that step you through the process and help you get it working right, so that’s why I’m going to blog it here and give you a working step by step…)
So VDI is effectively VMware / Hyper-V virtualization guest sessions for desktop users. Rather than an administrator remoting into a virtual host to access a server guest session running on Hyper-V, a user basically remotes into a virtual guest session running their copy of Windows 7 (or XP / Vista) desktop. As you know about server virtualization, the remote system can be almost anything, a PC or a pretty dumb terminal system, all the processing horsepower is done at the server and the actual applications are all centralized at the server as well. Microsoft’s rendition of VDI uses the tried and proven Remote Desktop Connection (RDC) that administrators use every day to remotely manage their servers, although the “VDI client” is a much improved and updated version of the client (more efficient over a LAN and WAN) and you don’t even need to load the RDC client at the desktop, you can actually just hit a Website URL and initiate your VDI session.
So basically a user just sits at a pretty dumb terminal / system, goes to a Website URL, clicks to initiate a desktop session, and they remotely connect to their “desktop” running on a Hyper-V host server in a datacenter. There are 2 different ways desktop sessions are doled out. You can have a “personal desktop” or a “virtual pool”. The personal desktop means every time you get a VDI guest session it is the exact same dedicated session just for you. The virtual pool is a series of sessions that are available that remote users “share”, so the base guest session is shared, but through a seamless use of “roaming profiles” type of configuration, the user experience is unique to that guest session so that even if they go back into the virtual pool and get a different guest session, their files, profile configuration, etc come with them and they see the same experience pooled system to pooled system.
This now goes to my point about where VDI fits in the marketplace. VDI doesn’t really decrease the number of “systems” I need, if I had 100 employees, I’d need 100 of these VDI sessions running on servers in the datacenter. And since VDI chews up RAM and CPU just like a regular workstation, if I give each employee 2gb of RAM to use, that means I need a pooled 200gb of RAM on my backend servers. Assuming 64gb per server, that’s at least 4 big beefy servers running these 100 user sessions. And it’s not like I decreased my management and administration either because with 100 guest sessions running, I still need to patch and update 100 “systems”, they happen to be sitting on 4 servers not spread across the floor of an office, but still, I need some “tool” to patch, manage, and update the systems. If you already have a good patch management system to update 100 desktops across a building, then you already have a process to deal with your desktops. If you don’t, you’ll need to get one for VDI as you still have 100 “systems” and in fact you now have 200 systems to deal with as you have the 100 systems running on the 4 beefy servers, you have 100 “terminals” or something to deal with too.
I heard one guy say “but yeah, for those 100 terminals, I can just grab a cheap / dumb terminal out of the closet and put it on someone’s desk if their terminal dies”, which is true, but as you all know, hardware is not really the issue for us these days. The problems users call helpdesk is because they accidentally deleted something, system is running slow (because they download crap onto their system that’s slowing their system down), or something software/system related. In VDI, you still have those problems, granted the problems are now centralized in say 4 servers, but you still have 100 “desktop” (sessions) to deal with. And when a user guest session starts chewing up memory and processing capacity, it now impacts other users on the shared servers, so you still have to deal with the “problem.”
Okay, so where DOES VDI fit? Where we’ve found VDI fits is for organizations that are using Citrix or Terminal Services for user access that need a handful of “unique” or special configured systems, the old 80/20 rule. Citrix / Terminal Services is a much better solution for the masses. Instead of “dedicating” guest session space for each user, Citrix / Terminal Services is much more resource optimized, and something that has been around for over a decade providing extreme value. The Citrix / Terminal Services model has just ONE system image on a host server and dozens of users access that same hosted image with each using having a unique / personal profile. We’ve scaled Terminal Services farms where we can get 50-200 users on a single host server (these days with 64-bit hosts, 64gb of RAM, 16 core we’re now pushing 250-300 users on a single host system. And, it’s just 1 “image” on the system so I can patch/update 1 system and it addresses the needs of 250-300 users all at once. Unlike 250-300 VDI users that each have their own session to patch and update, and dedicated 1gb or 2gb of memory spanning 5-6 host servers, Terminal Services / Citrix is much more efficient.
However, Terminal Services / Citrix solves the needs of 80% of a user base, a lot of organizations have cited that thin client model as not meeting the needs of “all” of their users, and thus have chosen to not do the Citrix / TS model at all. Now with VDI, an organization can provide 80% of their users with a Terminal Services guest session, and the 20% with special needs go to a VDI guest session. From a single interface, with common “terminals” on 100% of an organization’s desktops, some users go to a Terminal Services session and some users go to a VDI session. The users themselves never know, it’s all handled by policies, and given the 100 user scenario, you can easily have 1 Terminal Server handling the needs of say 80 of the users, and 1 VDI server handling the needs of the 20 VDI users, and with 2 physical hosts (instead of 4 I noted in a VDI only scenario), and now the 1 TS host plus 20 VDI guests to patch and update instead of 100 VDI guests to patch and update, you can now see the business value and economy of scale…
Microsoft has a huge leg-up on this mixed Terminal Services / VDI scenario because they’ve had Terminal Services for years, and with the latest updates in Windows 2008 and 2008 R2, TS actually addresses issued complained about in the past like remote printing, single sign-on security, etc that are all now included in the latest rendition of Terminal Services (actually they call it Remote Desktop Services (RDS)). I covered RDS in a previous article titled “Remote Desktop Services (RDS) – Formerly Known as Terminal Services”. From a single client interface, administrators can create a solution for both RDS and VDI users addressing the needs for all desktop users.
So what we’ve found, if you are an organization that is already using Citrix or Terminal Services today and need a little more flexibility for specific user needs, then adding VDI to your existing Citrix / TS environment for dedicated personal guest sessions is perfect. Or if you have considered going to a common Citrix / TS type platform but wanted more flexibility, doing a combo Windows 2008 R2 RDP plus VDI might be a way to go…
My next post, Part 2 of this thread will be specifically HOW you can setup and configure VDI to get it working in your environment.
