VMware View is good news, bad news

VMware's VDI solution makes virtual desktops real, but not particularly easy to manage

Page 4 of 4

Beyond the software clients, there are several companies producing thin client systems that have embedded VMware View clients. These units are designed to connect to a VMware View server and offer all of the options View supports.

Regardless of connection method, whenever a user authenticates to the VMware View server, they are presented with a virtual Windows desktop that works exactly the same as the physical Windows desktops they're used to. The one difference: In addition to logging out of the session, they can now disconnect. Disconnecting allows them to reconnect from anywhere and resume where they left off, while logging off will necessarily close all open applications and present them with a clean slate at the next log-in.

When running over 100Mbps Ethernet with the VMware View Client, the experience is roughly the same as with a local desktop. Of course, the overall experience is highly dependent on the specs of the desktop VM, such as RAM and CPU allowance, but when VMs are properly configured, most users are unlikely to notice much of a difference.

Users running from remote locations or via the Internet will see some sluggishness inherent with RDP (Remote Desktop Protocol), and high-latency connections will suffer somewhat too. This is a well-known factor present in all RDP connections, not simply VMware View. As with Citrix and Microsoft Terminal Services, it's best to know your users and what they need before deploying any form of virtual desktops. Users that require lots of CPU and RAM to run applications like Photoshop are not generally suitable for VDI, much as they aren't for other forms of remote desktop access.

Speaking of remote users, VMware View can be deployed to allow remote users to access their desktops from any browser anywhere. This comes in the form of another VMware View server built as a security server -- essentially, a Windows server that resides on the DMZ and acts as a proxy to the internal VMware View server. This removes the need for the internal View server to be Internet accessible and offers some measure of protection from external threats. The setup and configuration of this security server is extremely straightforward, requiring only a few open ports between the two systems, as well as to the security server from the Internet.

All in all, VMware View is a functional VDI implementation with more than a few quirks and foibles. If carefully administered, it's a suitable option for a VDI implementation, though there are several places where substantial improvements could be made, specifically in desktop pool administration and the entire Web-based management UI.

VMware's main competitor in the VDI space is Citrix's XenDesktop (see review), which is quite a bit more advanced in terms of management and administration, but lacks the VMware VI3 back end when run with the native XenServer. No big surprise here: Citrix is better at desktop management and VMware is better at core virtualization fundamentals.Regardless of the VDI technology used, implementing VDI could be considered more of a political than a technical challenge. Users tend to bristle when the core of their work is disturbed and will be quick to point out flaws and problems, whether or not they exist. You'll want to make sure that the VDI build is as solid as possible before beginning a small-scale pilot.

Also problematic with any VDI initiative are the desktop options available. At the moment, eight-year-old Windows XP is the most popular candidate to form the VDI baseline. This is a problem from several perspectives and affects all VDI products. With Microsoft Vista apparently dead in the water and Windows 7 still in beta, it's unfortunately not an issue that is likely to be resolved soon.

| 1 2 3 4 Page 4