VMware View is good news, bad news
VMware's VDI solution makes virtual desktops real, but not particularly easy to manageFollow @infoworld
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.
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.