VMware View is good news, bad news

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.

The Web interface is workable, but fairly picky about which browser is used. I could load the management interface in Firefox, for instance, but the page layout was significantly broken and I wouldn't trust it for day-to-day management. Surprisingly, I had better luck with Safari. Not surprisingly, I also had better luck with Internet Explorer.

Nevertheless, some functions were just messy. For instance, hitting enter instead of clicking OK after filling out a text field in a JavaScript config dialog might drop you back to the main admin page, losing all the configuration parameters you may have entered or changed. All in all, not a reassuring situation when you're dealing with what might be a few hundred user desktops.

Everyone in the pool

Once the core components of View are installed and running, at least one desktop pool needs to be built to support the users. The primary source of the desktop pool is a single VM that's built like any other Windows VM. The base OS is installed, then patches and service packs, followed by applications, and so forth until the VM is completely prepped and ready for a user. This source VM is then joined to the domain, and the VMware Agent is installed. The Agent is a small piece of code that runs on every View desktop and permits interaction with the View server.

Additionally, all the Microsoft Sysprep code must be installed on the vCenter Server to facilitate the automatic building of new desktops from the single image. This is the code that permits Windows machines to be cloned and run on the same network as unique entities, with various unique parameters such as the SID (security identifier) modified during the cloning process.

Once all those pieces are in place, the source VM is shut down, and a snapshot is taken of the system. This snapshot forms the basis of all subsequent desktop VMs.

Back in the VMware View Web interface, a desktop pool can now be created. Desktop pools can be built in several ways. The most common is likely to be linked clones. This method is used by View to allow for a large number of desktops without requiring that each desktop have a separate base disk image. Even a small desktop VM might require a 10GB disk, and creating a pool with 100 desktops would then require 1TB in storage. However, using linked clones, the total storage requirements of 100 users will only require a fraction of that space. View manages this trick by using the snapshot of the source VM as a baseline and creating links to that baseline for each VM. Thus, each desktop runs as an extension to the primary, with any and all changes made to the VM during normal use stored as a delta to the original. Also, View offers the option of creating a user disk with a fixed limit for users to store files separately from the linked clone.

In production, you'll want to use Microsoft Active Directory Group Policy to limit or prevent users from storing anything locally to the VM or to the user disk by redirecting My Documents and other directories to file shares served elsewhere. This is very similar to a normal Microsoft Terminal Services or Citrix installation.

The pool of desktop VMs can also be created with support for persistent or non-persistent desktop sessions. The difference here is whether or not a user is tied to a specific desktop instance, or if they simply log in to the next available desktop. In a call-center scenario, non-persistent desktops are probably the best idea, since users likely won't be using more than one or two applications, nor will they need a place to park their personal files.

Otherwise, persistent desktops are likely to be the best bet. This assigns a specific desktop to a specific user during their initial log-in, and they will always be connected to that desktop for each subsequent log-in, much like they would with a physical desktop beneath their desk.

Regardless of the parameters, creating the desktop pool is accomplished the same way: via a JavaScript-based wizard delivered from the View Web interface. It's not pretty, but it gets the job done. There are some caveats to be mentioned, such as the inability for a desktop pool to be properly created if the source VM maps to a floppy or CD-ROM ISO image. In fact, pool creation will fail if this is the case, with seemingly nonsensical "File not found" error messages. Only by changing the mappings to "Client Device" will the pool build as it should. This is decidedly non-obvious and became a very annoying issue in my deployment. Judging by the number of questions asked about this problem on VMware's forums, this is a relatively minor problem and easy to fix, yet is largely unknown and poorly documented. As with VMware's ESX and vCenter products, the error messages and logging in View could be greatly improved to alleviate such problems.

Following the creation of a linked clone pool, View uses the snapshot taken of the source VM to devise a baseline desktop instance, and then builds the remainder of the desktop pool from that image. Each desktop is assigned a name derived from the baseline name given in the setup wizard, followed by an incrementing number. Each Windows desktop is also Sysprepped and readied for log-in. The time required to construct this farm varies greatly, depending on the number of desktops produced, the speed of the VMware ESX host, and the speed of the storage behind the host. Once generated, the pool is visible in the VMware ViewAdministrator, and security settings can be assigned.

With VMware View, it's possible to formulate any number of desktop pools and assign them to various Active Directory user groups. For instance, you might have a pool for finance, a pool for engineering, and a pool for executives. Each pool might have a different source VM containing different applications, RAM allocations, and CPU allowances, and the pools would be assigned to varying groups for appropriate access.

To end-users, all of these desktop farms appear as options in the client, and users can access their desktops by selecting the appropriate pool.

One of the major benefits to VDI is the ability to quickly and easily add and remove applications, patches, and service packs to large numbers of desktops. With VMware View, this is handled by rebuilding the desktop pool from a different source snapshot than the original. To accomplish this, the original source VM is booted, the necessary changes are made, the source VM is shut down, and an updated snapshot is taken. Then the desktop pool is edited in the VMware View Administrator, whereby each desktop in the pool is shut down, rebuilt from the new source snapshot, and placed back into active service. This can be done immediately, forcing all users to log off, or it can be done gradually, as each user logs off his or her session.

Updating the desktop pool is not a fast process, though that speed is highly dependent on the storage in use. It should be noted that even small changes to the pool, such as modifying the RAM allocated to each desktop VM, require a complete pool rebuild. This should be simpler, but nevertheless beats the process for updating physical desktops.

Client-side View

There are a number of ways to connect to a View desktop VM. Linux, Mac OS X, and Windows clients can all use the Web interface and the Java client, while Windows can use a dedicated VMware View Client as well. Linux systems can also use the VMware View Open Client, which is an open source initiative by VMware to deliver a client that can be run on a broad range of platforms.

There are caveats to each of these methods, however. The best of the bunch seems to be the VMware View Client for Windows, which is slightly odd in that you need to be running Windows on a PC already, somewhat defeating the purpose of VDI. The Java client is very functional and runs well -- with the exception of video and audio reproduction -- on every platform I tested. Visiting YouTube while connected with the Java client is essentially a non-starter, with poor video and spotty audio. Audio streaming alone was better.

The VMware View Open Client for Linux is arguably the fastest client, but does not support audio or USB redirection, which will make it unusable in many installations. This is a shame, since this client could form the basis of a simple transition from physical desktops to VDI by allowing admins to leverage existing hardware to attach to the VMware View farm without paying for additional licenses. From what I understand, the lack of these functions is legal and political, not technical. Hopefully these artificial hurdles will be overcome soon. The Open Client really needs to be fully functional, or it's just not viable.

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.