VDI is a term that is thrown around a lot lately and in many ways.
the acronym stands for Virtual Desktop Infrastructure.
In its most basic description, this simply means that the operating system runs in a location that is separate from the end use the is interacting with the operating system (and using applications that are running within it).
This is only one form of virtualization, which is also becoming a pretty broad reaching term in the computer industry and encompasses many forms of technologies and ways of presenting workloads.
In my definition I stated that the operating system runs in a location separate from the end user. What does this mean?
The operating system can be installed on a PC, or a blade system, or in a virtual machine. Most commonly these will be in some type of data center, but they don't have to be.
I need to mention that MSFT has recently muddied the waters by using the term Remote Desktop Services to both describe VDI and Terminal Services (and possibly the application formerly known as SoftGrid) - a very generic marketing term to encompass the many ways to use various virtualization technologies to get an application to a user. When it gets down to implementation and design - it is important to separate each of these individual virtualization technologies.
Technologies that loosely enable VDI have been around for years and vary greatly. Back in the stone ages of IT we had PCAnywhere and a modem, we would dial directly into an awaiting PC and use its desktop from some other location. Today we have a similar technology called GoToMyPC. These were great for very simple one to one relationships of user to desktop.
Over time all of that has grown up into the enterprise level products that we call VDI today. In today's scenario the relationship and control is far different. It could be many users to a single source desktop (desktop pool), or the more traditional one to one (CEO to specific desktop).
This has evolved out of the need for both flexibility, control, and security. You no longer have to worry about the financial broker losing his laptop as there is no data on it - it becomes 'just a laptop'.
Today, most VDI infrastructures have some basic, common, components.
1) the end user
2) a control portal or broker
3) a transport / remoting protocol
4) the resulting target operating system
I don't think that I need to describe the end user.
The Broker is the portion of the infrastructure that provides access control - the user is required to authenticate, the broker checks that an assigned resource is available and then connects the two together. It also monitors the back end resources, sessions, prepares additional resources, etc.
The transport is how the devices at the end user remote back into the OS, as well as how the console of the OS (plus mouse and keyboard) get to the user. Again, back in the stone age there was VNC. And it is still around today. However, that basic KVM style remoting is giving way to RDP and ICA. From Microsoft and Citrix respectively. These are the protocols and not the client application that actually runs at the remote OS or the client device.
The target operating system is the operating system that resides in the data center or on-premise device. It is here that the applications actually execute.
There is also the more traditional Terminal Services which is strictly session remoting and uses one server to run many individual instances of an application and possibly a desktop.
These two technologies do directly cross over each other and in many cases Presentation Server or Terminal Server are a better fit than a full VDI infrastructure.
What is required in implementing a VDI infrastructure?
Places to run the workloads - hypervisor or blade systems.
Storage - that operating system needs to write and remember, as do the applications. In the case of pooled desktops, don't forget user profiles.
This entire article was prompted by a former co-worker of mine, Jeff Koch ('cook' that is). And I am sure that he will ask questions that force me to continue to expand.