Tue, April 07, 2009 — InfoWorld — VDI (Virtual Desktop Infrastructure) is seen by many to be an answer to the age-old problem of delivering a solid desktop experience to users without the administrative burden or costs associated with maintaining a physical desktop. Using a mixture of existing technologies, VDI enables users to log into a server-based Windows desktop session via a Web browser or Java client running on thin or fat client hardware. The virtual desktop promises users the same familiar Windows experience, while giving administrators central management and greater control.

I recently tested VMware's VDI solution, VMware View 3, both in the lab and in a pilot deployment on production hardware with real users. (I evaluated VMware View's chief rival, Citrix XenDesktop 2.0, in September.) The reality of VMware View is that it does work, but the management leaves much to be desired, and the user experience can be spotty.

Building a VMware View infrastructure is relatively simple, assuming that the major pieces of a VMware virtualization infrastructure are already in place. If you've already virtualized your server infrastructure, VMware View can be added as a companion in an hour or so. If you haven't already built a VMware infrastructure, then that's obviously step one. Generally speaking, it's expected that VDI will be an addition to an existing virtualization framework, and not deployed by itself. Given the success of server virtualization, this isn't a stretch. In fact, it's highly recommended.

[ Some challenges of virtual desktop infrastructure have yet to be addressed by any vendor. See Paul Venezia's "Five things I need from VDI." ]

Installation of View on an existing VMware infrastructure is accomplished by running the VMware Composer installer on an existing VMware vCenter Server, and then building a Windows server as a VM to run the actual VMware View services. This server becomes the View broker and is responsible for accepting user log-ins and directing them to their desktop once they've successfully authenticated to the system. The VMware View server does not have to be a VM, but it makes the most sense to do so.

Once the View server has been built, all administration of the VMware View infrastructure is accomplished not through the VMware Infrastructure Client, but through a Web interface hosted on the View server itself. This is a significant departure from the rest of VMware's offerings, which have included Web management but are generally managed by a central client. Given that vCenter Server supports plug-ins, it's curious that such a significant infrastructure component is not centrally managed.