The benefit of this scenario is one of scale: Generally speaking, you can probably shoehorn more Terminal Services sessions into a single physical server than VDI sessions, although that depends on the application set. On the flip side, in a VDI environment, it's possible to institute hard and fast resource limits to any user session simply by defining the resources of the desktop VM.
In a VDI implementation, that same server is running a hypervisor, not a full OS, and is hosting some number of desktop VMs. The end effect is that each method places multiple desktop sessions on the same server, but the manageability of those sessions differs significantly.
For instance, with Terminal Services, there's no way to snapshot a session like you can a VM, nor is there a way to migrate active sessions from one physical server to another. This means all users must log off of a Terminal Services server before it can be taken down for maintenance. With VDI, all of the active desktop sessions on that server could be migrated to other servers in the farm without disruption. The server that normally hosts all those VMs could be taken down for maintenance without anyone knowing.
Indeed, as with any advanced virtualization infrastructure, it's possible to completely rebuild the entire underlying physical server structures without taking a single application offline or interrupting a single user.
Further, load-balancing is intrinsic to a properly implemented VDI solution. If one or more desktop VMs are using significant resources on one host system, other VMs on that system may be migrated on the fly to other physical hosts, ensuring that all the desktops have enough resources to go around. In traditional Terminal Services environments this is not possible; a single heavy user session can negatively impact other sessions on the same server without any automated remedy.
But Terminal Services has one big management advantage: Changes made to the host servers are made available to every user session. Application installation is simplified to a degree and global modifications are relatively easy.
With VDI, that's not always the case. Depending on how the desktop VMs are deployed, updates and changes may require manually modifying each VM individually; using third-party management tools; or firing up a desktop VM template, making the changes, and saving the template. Desktop VMs that are linked to the master template will reflect the changes the next time the user logs on.
Nonetheless, application handling is one of the main benefits of VDI over Terminal Services. Many applications simply refuse to function in Terminal Services environments. Others have limited functionality or may not be supported by their vendor in a Terminal Services environment. This presents a real problem for any Terminal Services-based infrastructure, but it's generally not a problem for VDI.
Why? VDI implements a single dedicated desktop instance per user, indistinguishable from a physical desktop at the OS level. Any application that would run on a fat client should run on a VDI VM (with some exceptions made for video and graphics performance). This is a major reason some shops are pushing VDI over Terminal Services.
Read more about how to deploy VDI in InfoWorld's free PDF report, "Virtual Desktop Infrastucture (VDI) Deep Dive," including:
- Planning and implementation
- User acceptance and use cases
- Client considerations
- Beyond the walls: Remote VDI
- Bringing it all together
Read more about virtualization in InfoWorld's Virtualization Channel.