Design and Review: VMware View 4

VMware View, formerly VDI, is all about desktop virtualization, at the enterprise level. View integrates with and requires vSphere and vCenter on the back-end; Set up and configuration of these components is beyond the scope of this article.  The value proposition for View is heightened security and availability for desktops by moving them into the datacenter while reducing support costs due to centralized desktop image management. View can be used to provide and control access to VMs, terminal servers, or physical PCs and supports native MS RDP as well as PCoIP for an “optimized PC experience.” View services can be accessed via View, RDP or Thin client using several different display protocols.

The desktop in the datacenter proposition is an interesting one. If using persistent VMs then you can take advantage of the recomposition feature in View and dynamically update your parent image which will trickle down to all cloned VMs. Your desktops will also enjoy HA if hosted on an ESX cluster bringing a level of redundancy otherwise not possible with traditional PC hardware. Of course you will still need to procure and deploy thin clients on user desks that will consume an image in your View environment. Another benefit of this model is that desktops will follow users so no matter where they log in they will see their assigned desktop.

My use case is a little different. I have another stubborn app that (still) requires Office 2003 which has been long gone from my desktop builds for many years now. The terminal server solution works fine for this app but then we have a resource problem as particular functions of the app like to consume 100% of available CPU, starving the other connected users. For this particular case View is a great solution because I can deploy a desktop to each application user and guarantee a predictable performance level for each VM, eliminating contention. Through the View Connection Server I can broker client requests and direct my users to a single pool that will present their work spaces to them dynamically. In this project I will be integrating View into my production ESX cluster to provide 10 dynamic desktops to users of a business application.

View can be licensed in two flavors, Enterprise or Premier, VMware’s new scheme, and for new or existing vSphere customers. The key difference between the two is Premier comes with View Composer, Offline Desktop (experimental), and ThinApp. View Composer is required if you want to use the linked clone feature. Linked clones are spawned from a parent but are a fraction of the size (10MB) and point back to the parent. List prices range between $50 and $250/ concurrent desktop. Read more about the version differences here: VMware View.

Architecture

The required components of this solution are:

• ESX
• vCenter running View Composer
• View Connection Server (VM)
• Active Directory

The View Connection Server (VCS) will host the broker service that will direct clients to their presented desktops. VMware plainly states that this server role should not be installed on your vCenter server and must run on Server 2003 (R2) only, Server 2008 is completely unsupported at this point. VCS is fully supported as a VM in the cluster so no worries there. VCS can scale to support additional replica servers for large environments and security servers for DMZ deployments . A single VCS instance can support 2000 simultaneous connections (direct, RDP). VMware documentation can help you calculate overhead for varying workloads running on various desktop operating systems.

Here is my architecture as it will be implemented (terminal servers and PC are evolutionary considerations):

View Composer

While spinning up my VCS VM, I installed View Composer on my vCenter server. Although technically not supported, I was able to successfully install Composer on Server 2008 R2 with SQL Server 2008. First create a new SQL database for Composer where your vCenter database lives, View will use Windows authentication mode.  The key to getting through the installation is to set up the ODBC via the applet in the administrative tools folder (%windir%\system32\odbcad32.exe), not via the Composer setup wizard which will open C:\Windows\SysWOW64\odbcad32.exe.  Setup will only find a DSN configured with the administrative tools applet. If you use the applet called by the setup wizard you will get this error:

 

The rest of setup is straight forward and will result in the VMware View Composer service being installed and started. That’s it. There is nothing else to configure for Composer.

View Connection Server

Once the 2003 R2 VM is ready install VCS. VCS can be installed in one of 3 roles, for my purposes Standard is fine. Setup will also install an instance of MS ADAM to store View configuration data. After the first server is setup, if you need you can install replicas. The VCS will also run an instance of TomCat to host the View Manager website.

 

Parent VM

Before we configure View Manager, let’s get the parent VM ready. In vCenter create a regular VM with the desktop OS of your choosing, I’ll be using XP Pro SP3. Install all patches, needed software, antivirus, ODBC settings, and join it to the domain. Don’t forget to install the View agent as well and disconnect any floppies or CD-ROMs! Once everything is configured correctly take a snapshot in vCenter as this is what will allow the VM to be a parent in the View environment. This snapshot provides the baseline for the parent image.

View Manager

View Manager is the administrative tool used to configure View settings, accessed via a web browser. The site is accessed by connecting to your VCS server: https://VCS/admin. This is where you input your licensing information for your View environment which should be done first. Click Configuration, then Edit License under the Product Licensing and Usage heading. Next associate your vCenter server. You will need a domain service account that has administrative rights on both vCenter and VCS servers, as well as the ability to create and delete computer objects in the OU of your choosing in AD. This service account will be used to dynamically create VMs, join them to the domain, and then delete both when not in use. It does not need domain admin rights if properly delegated.

Add any users or groups that you would like to allow administrative access to View Manager. At this point we should now be ready to set up a desktop pool and start testing View. Click Desktops and Pools, then Add… to start the setup dialog.

There are 4 different pool types you can set up depending on your requirements, I’ll be setting up an automated desktop pool.

 

Desktop persistence will determine a few different features available to you after the pool is created. Persistent is suited for permanent user desktops and can be used with the parent VM recomposition feature while non-persistent will be temporary and cannot be used with recomposition. My View desktops will be used dynamically to run a specific application, not as permanent desktops so I will use non-persistent.

Along with non-persistent desktops I want to use the linked clone technology which will create clones of my parent VM that are a fraction of the size of the parent, 10MB per VM. This is very cool technology and huge disk space saver.

 

Configure a unique ID/ display name then move on to desktop/pool settings. Configure the desired behavior for each setting. I want to force the RDP protocol and destroy the linked clones when a user logs out.

Provisioning settings will determine the automated behavior of your desktop pool. I am licensed for 10 desktops but would only like 1 available at all times since they will not be used daily. As soon as a user logs into one another will start spinning up automatically .

Next select the parent VM you created and snapped earlier. Remember that only VMs with snapshots will be displayed here.

Once the parent VM has been selected you will see the snapshots attached to it. Select the appropriate snap and click next.

Setup will next create a folder in the location of your choosing to house the View VMs. It will name the folder based on the Unique ID you created earlier. Choose your host or cluster then select a resource pool and datastore. I’m not currently running DRS so I can’t create a resource pool in my cluster and am stuck using the default pool. Next move on to QuickPrep. This is where the integration magic is set up. If you set up your service account as I described earlier you will see it here in the dropdown. In the AD container box, enter the AD DN of where these VMs will live in your directory (in reverse order). Make sure to leave off the domain designations or setup will fail! (DC=domain,DC=com).

Review the settings on the next screen then click Finish to commit. You can now safely turn off your parent VM. Next you need to grant access to the users you want to be able to use the View desktops, this is done via the Entitlements… link.

Depending on your provisioning settings, you should now see at least the first desktop being created in vCenter. First View will create a replica source of your parent VM. This copy process will take a few minutes. Browse your datastore to see the new replica folder and files.

Once the replica is in place, linked clones will spin up much faster since they will point back to the replica source. Linked clones will continue to increase in size over time so it is a good idea to refresh them occasionally to reset their space consumption. When first created the linked clones are extremely small.

 

The View client should now be installed and users can log into the environment.

Although recomposition-on-the-fly is not available for non-persistent VMs you can still refresh your parent VMs, albeit a much more manual process which requires down time.

1. Destroy all desktop sources in the pool via View Manager
2. Disable the pool and new VM provisioning
3. Delete the snapshot on the desktop pool’s parent VM in vCenter
4. Make your changes and shut down the VM
5. Take a new snapshot
6. Edit the desktop pool in View Manager to point at the new snapshot
7. Re-enable the desktop pool and VM provisioning

Please note that by deleting the last clone in the pool will also trigger a delete of the replica. So when you enable the pool again the replica will have to be created again.

As of this writing only build 4.0.1-233023 is publicly available on VMware’s website. I was having a problem with provisioning where after a VM was spun up, View Manager would flag an error status and spin up another, even though the original was fine and fully usable. “View Composer agent initialization state error (6).

VMware’s posted solution to this problem is to create a batch script that reboots the VM again after the provisioning process has completed. This did not resolve the issue for me so I opened a case with VMware. They directed me to the bits for build 269620 which has resolved the issue! The download link I was given is public so I’m going to assume it’s ok to post here, see the references section at the bottom.

Client deployment can be easily accomplished using KBox, SCCM, or other deployment solution. Here is the command string I used to deploy in my environment (change the server name):

VMware-viewclient-4.0.1-269620.exe /s/v/qn DESKTOP_SHORTCUT=0 VDM_SERVER=<ServerName> REBOOT=Reallysupress

Conclusion

I am extremely impressed with VMware View and the lengths VMware has gone to, to ensure seamless integration into an existing enterprise environment. AD-integration is seamless as is desktop provisioning. I should not have to touch my View environment unless the parent VM needs to be updated. It is, however, additional infrastructure in what seems to be an endlessly expanding datacenter service footprint but the value and rewards are solid. If you already own or are planning to purchase vSphere and need a virtual desktop solution I strongly recommend you consider View 4.

 

References:

VMware View 4.0.1-269620

View 4 Architecture Guide

View 4 Deployment Guide

View 4 Admin Guide