The VMware Virtual Desktop Infrastructure (VDI) is more a concept than a distinct product —the concept being the ability host multiple desktops within a virtualization server, which currently requires more than just one product to accomplish.

VDI consists of four basic components: a client to access the Virtual Machines (VMs), a broker to direct the clients to the appropriate VMs, the virtualization server, and the VMs that are used as the desktop. There are several ways to fill each of these components.

The client that gives end users access to the VMs is usually the Microsoft Remote Desktop Protocol (RDP) but the client is generally dictated by the broker being used. Some other clients are VNC, or RDP or VNC over Secure Shell Tunnels.

The broker to use could be VMware Desktop Manager (VDM), Linux Virtual Server, Citrix Desktop Server, Citrix XenDesktop, Provision Networks VAS, Leostream CB, FreeNX () or a NoMachine Server , Clearcube Sentral, and Ericom PowerTerm. (This comparison of most of these products is well worth a read. This site does not review the Linux Virtual Server, or FreeNX solutions however.)

Given that there are so many brokers, VDI ends up being more than just a VMware product; it is a concept that includes multiple products.

Most of the brokers listed here only support Windows VMs; in most cases, the VM must support RDP in order to be used by the broker. Using additional tools like XRDP it is possible for most Linux systems to work as virtual desktops for all the brokers listed.

Most people, in picking virtualization servers, end up with the VMware Virtual Infrastructure; but VMware Server and XenServer are valid options as well. The choice among servers really boils down to manageability—the ease in which new VMs are created, the quantity of VMs the interface can handle, perhaps even a pool of already powered on VMs in order to improve the user experience

The security of these VMs should be assessed properly and the tools to maintain that security need to be in place. It is important to realize that this is a captured environment and hence all the VMs can be clones of one that could be constantly tested for security issues, patched, and redeployed without the users knowing about it.

Next on my list of important items is the access to the VMs through the broker, how is that security achieved? Using pre-shared keys? Standard SSL, or whatever RDP and Windows normally provides. Once more, this depends entirely on the broker chosen.