The solutions to this problem can be costly. Some vendors combine efforts on the server and client side and ship audio and video streams alongside the display protocol, matching them up at the client end and using the client's processing power to render the video. This results in much cleaner playback, but requires a more powerful and expensive thin client to handle the extended workload.
Such solutions work well for standard video playback, but they still have issues with Flash video and Flash applications. It's easy to test the performance of VDI or any other server-based desktop computing solution that uses the standard RDP protocol: Just use the Microsoft Remote Desktop Connection client to connect to a server or desktop system and try to view a video on YouTube. It may play reasonably well if you're using a 100Mbps or faster LAN, but it's simply a nonstarter over anything less than that. Generally speaking, watching a video across an RDP connection requires 3.5Mbps of sustained bandwidth.
Bandwidth concerns may dog any form of server-side desktop computing, such as serving desktop sessions across WAN links (a classic scenario for high latency and/or low bandwidth). Printing and proper mapping of USB devices may also be problematic. These issues can be sorted out with the right combination of tools and budget, and aren't exclusive to VDI, but they need to be addressed during VDI planning phases.
Other issues are clearly VDI-specific. The first and most significant: storage requirements. Some VDI implementations require that every desktop system have a virtual disk like any other VM. When you factor in 8GB or 10GB per desktop VM, multiplied by the expected VDI user count, storage quickly becomes an expensive issue. Also, it should be noted that VDI does very little to reduce desktop software administration requirements, because each VM is an island that must be managed like any other desktop system. That means using third-party tools to push updates, install software, and make changes.
And then there's cost. On one hand, VDI may leverage an existing virtualization infrastructure, possibly lowering the initial hardware cost below other server-side desktop computing solutions. But once you've broken through the layers of software licensing required for VDI, you may find that it eventually evens out. Depending on the solution you choose, you could wind up paying more per desktop VM than per traditional fat client system, with the ROI pushed pretty far out. It's vitally important to run all of these numbers before you jump into any VDI implementation. Factor in thin client costs, implementation costs, licensing, and expansion of an existing virtualization infrastructure.
VDI vs. Terminal Services
Distinct parallels can be drawn between VDI and traditional Microsoft Terminal Services solutions. They both place many user desktop sessions on a single server or set of servers and they both use the same protocols to deliver those sessions to the same thin clients. Both offer centralized desktop management tools. But the similarities end there.
A Terminal Services environment places all user sessions on the server OS itself. This means that a single instance of Windows Server 2003 or Windows Server 2008 is installed on a bare-metal server, and all users log into that server instance. Each user session is presented with its own desktop, but runs alongside all the other sessions on that particular server.