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.