Everything you always wanted to know about VDI but were afraid to ask (no, it's not an STD)
All you need to make virtual desktops go
Feature So you know your way around a data center just fine, but you've been told to roll out VDI – aka that highly riveting technology, virtual desktop infrastructure. This is your first time juggling virtualization on this scale. What do you need to worry about? How will you test and benchmark it?
Our sysadmin blogger Trevor Pott presents this handy cut-out-and-keep guide, complete with four scenarios for you to work with.
In any VDI setup there are four major elements that will determine the performance and user-friendliness of your system: the graphics; your network bandwidth; your servers' resources; and the storage of all that data. If any one element is out of balance with the rest, your virtual desktop beast will fail the user.
As well as these elements, VDI has three basic flavors in the Windows world: Remote Desktop Services (RDS, formerly known as Terminal Services); Windows Server VDI; and Windows Client VDI. In the latter two approaches, each user gets one virtual machine all to themselves: one user per operating system instance.
In an RDS scenario, multiple users log onto a single Windows Server instance and share that installation. Multiple RDS servers can exist in the VDI pool, but the differentiator with RDS is that concept of multiple users logged on to a single copy of the operating system.
This multiuser concept has real-world significance. An application installed on the RDS server is available to all users and must be licensed as such. An anti-malware sweep against the OS will affect all users, and it is possible for one heavy user to degrade the experience for all other users. (Though Server 2012 and Server 2012 R2 do have quite a few nice new technologies to thwart processor hogs.)
Perhaps most critically, you may have applications that are not exactly multiuser friendly. One user crashing an application can break it for all other users, and if someone manages to crater the OS, they take it out for everyone.
The alternative "one user per operating system" model employed by Windows Server VDI and Windows Client VDI uses more space and resources per user, but eliminates the possibility of one person ruining it for the rest.
Unfortunately, licensing Windows for the aforementioned three basic types of VDI differs substantially from flavor to flavor, and you should investigate which approach is right for you. Since today we're discussing the engineering side of implementing VDI, this article won't go into the nitty-gritty of licensing (although this PDF should be your first port of call). Instead, we'll roll onto the elements that make up a decent VDI stack.
Graphics: Don't get squeamish about the graphic detail
Generating on-screen graphics is most often the single biggest drain on any VDI setup. It is also the most frequently overlooked consideration and the least understood by those new to the field.
Everyone should know that the general-purpose processors in PCs offload graphics work to dedicated GPUs: the most basic graphics processors in today's desktops can rapidly render 2D and 3D scenes on large (or multiple) monitors.
This spares the general-purpose CPUs from having to juggle graphics plotting and the compute workload of your daily dozen, thus maximizing performance all round.
Without GPU virtualization, VDI deployments must not only handle the usual CPU demands of applications, they must create virtual GPUs out of CPU resources for each VDI instance you provision. Even the most powerful x86 servers can be quickly felled by a handful of VDI users streaming video from their virtual machines, something that happens more often than you may think.
The number one element that is going to affect your score in VDI synthetic benchmarks is graphics generation. Even if every element of your deployment is well balanced, if you are relying on your server CPUs to provide graphics for your VDI instances, your score is going to be pretty bad.
This doesn't mean that the real-world results will be bad. This is where understanding your users and their workload comes in. Are your users going to be doing a bunch of word-processing and spreadsheet work with no video, animations, and so forth? If yes, you can get away without the GPU virtualisation. Are your users going to be doing a lot of image-heavy work or watching training videos?