An introduction to VMware View 3, Part 3 of 3 – Special Considerations and Best Practices

High available, secure remote access

Unfortunately, a high available configuration to access VMware View while being outside the corporate network can be very different between organizations. I have been doing some research reading the VMware VDM 2 Load Balancing Guide to find out more about load balancing and secure remote access. In today’s enterprise environments, gateway devices like Citrix Netscaler/Access Gateway or Cisco ASA are more or less common practice. They are configured as a mandatory termination point for sessions originating from outside the corporate network connecting to resources inside the corporate network.

Initially, two http sessions are set up between the client and the Connection Servers to which the load balancer redirected the client request. One session is for communication with the web page, the View Portal, and one is for the RDP connection that can be configured to be packed into http or https. By default, a Connection Server replies to the client http request with a response in which its own hostname is sent back to the client. Using the default configuration of a Connection Server would then result in having to open up the necessary ports on the firewalls between the Gateway device and all Connection servers as the client will try to communicate directly with the Connection Server once it received the Connection Servers’ hostname in the http response. In the configuration page of the View Administrator however, you can modify the default behavior by configuring an ‘External URL’ that will be given back to the client. The External URL will have to be configured on each Connection Server that you have.

Picture 16 – Part of the screen that appears when clicking a Connection Server and choosing ‘Edit’.

An External URL can be configured and also a direct connection to desktops, resulting in bypassing the Connection Server for direct communication with the virtual machine that a user needs. If you configure the External URL to be the DNS name of the load balancer, you will have two moments on which load balancing will take place; initially to set up the communication to the View Portal, and subsequently, if a session to a Virtual Machine is started.

According to VMware in the Load Balancing Guide, for proper load balancing to work the load balancer needs to be configured for SSL Offloading. SSL Offloading is necessary because a load balancer cannot see what’s inside an SSL request. All requests are coming from one Gateway device, which means that all the load would go to the initially chosen Connection Server. Also, sticky sessions need to be configured on the load balancer to support RDP connections over http. This means that SSL connections can be setup to the load balancer, but the load balancer will strip off the encryption and forward the requests to the Connection Servers as http. This actually means that communication from the load balancer to a Connection Server is going over HTTP where, for example, a cookie insert by the load balancing device will result in being able to provide RDP sessions consistently going to the same Connection Server

1. This also means two more things:
2. Username and password are passed to the Connection Server in clear text between the load balancing device and the Connection Server.

As the Connection Server is configured for http and not https, the RDP sessions will be packed in http as well. This might not be a problem because the connection from the internet to the Gateway device is already tunneled in https, but I wanted to point that out anyway.

Compared with Citrix Web Interface, where integrated logon with Kerberos authentication is an option, this seems like an issue that VMware could address better. Also to get a Cisco ASA to work, probably a View Plugin for ASA would be a GREAT idea…

Server Provisioning

When I made the comparison of View 3.0 with Citrix Provisioning Server, I wondered how View 3.0 could be used to deploy Terminal Servers or even Citrix Servers. The official line from VMware says that only Desktop Operating Systems are supported. I tried it for myself and, indeed, a Virtual Server with a snapshot and a View Agent installed is not ‘discovered’ in a desktop pool deployment wizard. Too bad, because a tool for cloning Citrix servers, like the one from CitrixTools.net could do a good job here, handling all Citrix specific services and settings with Sysprep being used by Virtual Center to deploy uniquely identifiably virtual machines. Active Directory policies could be adjusted to make all this work without further administrative interaction.

Maybe I’m going too far here comparing View with XenDesktop/Provisioning Server? I see a lot of similarity between the two products, even though entirely different techniques are used. I might say that putting OS changes in a ‘memory state cache’ as Provisioning Server does is a more elegant solution than creating and deleting snapshots, but the result can be the same; Instantly provisioned machines that are deleted as soon as they reboot.

Machine Account password

A virtual machine with a snapshot can only be used by View 3.0 (or probably VMware ESX) as a master image if the machine is joined to a domain. For this reason, I would apply the same local policy as I would normally do with a sequencing or packaging machine, and then disable Windows machine account password resets. If your company policy or personal preference requires machine account password changes, you can change the default ‘change password interval’ to the maximum of 999 days. Both of these options can be changed in the Group Policy editor:

Start/run/gpedit.msc >

Computer configuration/Windows settings/Security settings/local policies/Security options:

- Domain member: Disable machine account password changes – enabled

- Domain member: Maximum machine account password age – 999 days

Display Protocol

I have to mention that I was at least a little disappointed when I noticed that nothing was done about optimizing RDP. It is especially important if you plan to deploy Windows XP, which probably has the worst version of RDP still available, and you have to provide desktops to users over high latency connections. I must admit that I haven’t yet tested performance using RDP with a typical Indian latency of (so the story goes) up to 300 milliseconds, but I can image implementations being cancelled because of this shortcoming. The Group Policy Administrative Templates provided with View will really be necessary to optimize RDP as far as possible, but of course the advanced options available in ICA are really an entirely different story.

In the Reference Architecture Kit on the VMware site, VMware actually acknowledges this problem by stating that RDP is a good protocol for LAN connections or WAN connections with up to 150 ms latency. If you have to provide virtual desktops over high latency connections however, using RDP might not be a good idea. VMware mentions solutions like Sun Microsystems’ Appliance Link Protocol™ (ALP) used in Sun Ray™ thin client implementations and Pano Logic’s Console Direct, but getting into those is out of the scope of this document. I did find a network tool that can configure latency up to 400 ms, so I will test this in the near future.

Sizing

Also in the Reference Architecture Kit, a setup is described for separate ESX clusters for VDI. For my customer, I will also use separate ESX clusters. Although, since clusters cannot contain more than 8 nodes, my customer will have to change from their standard cluster configuration of 13 hosts per cluster. I found that approximately 17 power users can be placed on a machine with two quad core CPU’s and 24 Gb of memory. Because of the memory sharing feature, ESX even promises to be the best option on which to run VDI environments, as other hypervisors do not support memory sharing. I plan to use the same Virtual Center that I already have running for my server environment, which already is one of the largest in Europe. However I will probably have to keep a close eye on performance, as Virtual Center probably also has its limits.

User experience monitoring

When you are planning to use VMware View, I recommend looking at ‘User Experience Monitoring’ products. Products from eG Innovations and RTO PinPoint can provide valuable information on both frond end and back end performance, giving you great insight in what delay is caused where. Implementing that could save you a lot of time in the end.

A final word or two…

VMware did a good job with View 3.0. They put all configuration options for the View 3.0 product into one console, which is really excellent work. The console is intuitive and fast. Options are logically grouped and put into only four distinct console windows. The new linked clone technology is probably a bit harder to understand as consequences for disk space usage are not properly documented by VMware. (Linked clones were covered in Part 2 of this article series)

The term ‘persistent desktop’ needs some explanation because it can be misunderstood as a desktop for power users – like a dedicated desktop. In actuality, it means that all the desktops are kept in a consistent state by the administrator, which is certainly not a “power user” type desktop.

Furthermore, most essential options are available; universal printing, single sign-on, instant and automatic desktop creation, even the experimental ´offline desktop feature´ can be used. Unfortunately, optimizations on the RDP protocol are lacking, which in some cases might result in unworkable situations because of network latency. Customers using VMware ESX could strategically choose for View 3.0 because of the tight integration with Virtual Infrastructure. With the Premier license bundles that also includes ThinApp/Thinstall, the combination makes for a promising offering in the VDI market. I wonder what VMware´s next move will be.

Useful links

VMware VDM 2 Load Balancing Guide

Administration Guide – View Manager 3.0

VMware View Reference Architecture Kit

An introduction to VMware View 3, Part 2 of 3 – Linked Clones

Linked Clones

The big question to most people is probably: ‘What are linked clones and how do they work?’. Some of you may expect similar functionality to Citrix Provisioning Server where optimization in disk space can be significantly realized, and indeed VMware does somewhat the same, but with very different technology. Let’s see how VMware does it.

The essence of linked clones is Thin Provisioning; saving on expensive storage cost. Thin provisioning with View 3.0 can be realized using a “master virtual machine”, which is just a regular virtual machine that you create and then take a snapshot. That virtual machine will be used as the basis for rapid and thin OS deployment. Please notice that I mentioned a virtual machine “snapshot”, not a virtual machine “template”.

You prepare a virtual machine with the Desktop OS of your choice (Server Operating Systems are not supported) exactly the way that you like your master image to be. When all components and settings are properly set, you then have to install the VMware View Agent (which contains the components mentioned in the previous article), shut down the virtual machine and take a (first) snapshot. I might add that the master virtual machine has to be domain joined, for which I could not find the reason. After that, desktop deployment can start.

In the View Administrator console, choose the ‘Desktops and Pools’, as this is where desktops and desktop pools can be added and/or edited. In the right pane of the ‘Desktops and Pools’ tab, five other tabs appear, the most left being the ‘Desktops and Pools’ view. Here you can choose ‘Add’ to start a wizard that guides you through the steps necessary for adding a desktop or a desktop pool. The following choices are presented:

• Individual Desktop, this option will start a wizard to provide users with access to a single virtual or physical computer on which the View Agent is installed.
• Automated Desktop Pool, this option starts a wizard to automatically create one or more desktops in a pool. The explanatory text for this option states that desktops are based on “virtual machine templates,” which is wrong.  You need to have a normal virtual machine from which you will take a snapshot (as mentioned above). 
• Manual Desktop Pool, this option will start a wizard to provide access to an existing set of virtual or physical PC’s that have the View Agent installed.
• Microsoft Terminal Services Desktop Pool, this option starts a wizard to publish Terminal Server desktops to View Portal users.

I don’t want to get into details with every option mentioned, but continue with the most eye catching option, the Automated Desktop Pool. The automated desktop pool can consist of any number of persistent or non-persistent desktops.

After a persistent desktop pool is created and a user is assigned a certain desktop, the mapping between user and assigned desktop is written to the ADAM database (see Part 1 for more information on how ADAM is used). Every time the user logs on to the View Portal, the same desktop will be available and the state of the virtual machine is exactly the way he or she left it with the previous logoff. This option is similar to the ‘permanent disk’ in Citrix Provisioning Server. A persistent desktop pool can contain any number of desktops, and once created, the pool can also be edited to increase the number of desktops in the pool. In the wizard, as depicted below, the initial number of desktops to be created is set to 5, the total number of desktops in the pool is set to 100 and as soon as the number of available desktops falls below 5, the number of available desktops is matched to meet the configured criteria by creating more machines in the pool, until the maximum number of desktops in the pool is reached.

Picture 6 – Advanced configuration of the number of desktops in a pool in the Deployment Wizard

Both persistent and non persistent desktops can be created using the ‘linked clone’ technology, which in fact means that deployed desktops can be altered by assigning the desktops to a different snapshot or even to an entirely different virtual machine. The main difference between a persistent and a non persistent desktop is that persistent desktops can contain a second virtual disk to which the ‘Documents and settings’ folder is moved. User data is effectively put on another disk, so in case an administrator decides to assign a different snapshot or image to a user, all user data in the ‘Documents and Settings’ folder will still be available. Of course, this can also be accomplished by modifying the User Shell Folders of each user with Active Directory GPO or script to alter all default folders, but with the View 3.0 option, user data will be locally available, presumably resulting in better performance.

I wonder if this is really a useful option, as user data can only be reached by going to the machine itself and opening the folder, whereas with folder redirection, all user data can be redirected to a central network share, substantially simplifying central administration, in my opinion. If the central network share is located on fast NAS heads, performance might still decrease a little, but management of user data only locally available on virtual machines is not a very attractive option in larger environments.

Picture 7 – A separate disk for personal data, available in a linked clone.

What actually happens as the wizard is finished is that a copy of the master virtual machine is made, together with a copy of the snapshot. The size of the copies, however, is not a complete copy of the master virtual machine. I deployed a master image with a system drive of 20 GB with a snapshot, which resulted in a copy of 6 GB for the system drive and a few Kb for the snapshot.

Picture 8 – User data drive of a persistent desktop for a specific user.

The folders and disks are automatically created and the folders and files contain some GUID that is associated with master desktop and user.

To (hopefully) clarify the components, the following Virtual Center folder arrangement is depicted:

.jpg”>

Picture 9 – Virtual Center containing all folders necessary for a View 3.0 deployment.

The above picture shows that

• VMware virtual machine templates can be used to deploy master images
• Master images with at least one snapshot are best placed in a separate folder to make sure you don’t mix things up
• Linked Clones are best placed in a separate folder, where subfolders can be created to place non persistent and persistent linked clones
• You can (and probably will) have other virtual pc’s or virtual servers in your Virtual Center
• On the bottom of Picture 9 the automatically generated folders are shown, which are all created by View 3.0 as a result of a desktop pool deployment wizard in the View Administrator console. A replica folder and a source folder are created for each desktop pool that uses linked clone technology. All folders created automatically are fully managed by View 3.0 and are only to be administered through the View Administrator console.

Linked Clone disk characteristics

So, how does View 3.0 handle disks and disk space for linked clones?

In my tests I created a Windows XP SP2 image with a system drive of 20 GB. In the Automated desktop pool wizard, I chose to configure 5 linked clones, where initially 1 linked clone was created immediately after finishing the wizard, and where always 1 desktop would be available for new user logon until the maximum number of desktops in the pool has been reached. Also I chose to create a separate User data disk of 2 GB for the ‘Documents and Settings’ folder to be placed.

Picture 10 – Step in deployment wizard where OS Data and User Data stores can be selected with.

After finishing the wizard, a replica folder and a source folder are created which are used as templates, of which clones are created by View 3.0

Picture 11 – Replica folder of an automated, persistent desktop pool, derived from a 20 GB system disk

Picture 12 – Source folder of an automated, persistent desktop pool with a configured user data disk of 2 GB

Picture 13 – System disk of a linked clone, available to an end user using a system disk of 20 GB

Picture 14 – User data disks, mapped as D-drive in the users’ virtual desktop, for two users with a maximum of 2 GB per user

In the table below, all components are mentioned to deploy at least one desktop pool based on one Desktop Operating System. The ‘linked clone system disk’ will initially be around 100 MB and can grow up to the original size of the Master VM. A Desktop Refresh (discussed below) can be scheduled or executed manually to return the linked clone system disks to its’ original size.

System disk of Desktop OS template, used to create ‘Master Image Virtual Machines’	20 Gb
System disk of a ‘Master Image Virtual Machine’, containing a Desktop OS including (a) snapshot(s)	20 Gb
Replica folder and source folder derived from the ´Master Image´, created for a desktop pool with an unlimited of linked clones	6 Gb
Linked clone system disk per OS	100 MB – ??
Linked clone user data disk per user	2048 MB (configurable)

Table 2 – Linked Clone disk size example

Desktop recompose, refresh, rebalance

At all times, deployed desktops can be altered when created using the linked clone technology.

A Desktop Recompose means that a deployed desktop state is altered. It can be assigned a different snapshot of possibly even entirely an different master virtual machine.

A Desktop Refresh means that a linked clone desktop is brought back to the state of initial roll out. This actually means that the system disk is reverted to the moment it was deployed, including its size and contents. If a separate user disk was used in the deployment wizard, all user data on that disk remains intact.

A Desktop Rebalance means balancing virtual machine disks across available data stores (LUN’s). If a VMware ESX data reaches its capacity, a rebalance can take care of automatic data migration of deployed virtual machine disks to different ESX data stores.

Picture 15 – View on a persistent desktop in the ‘Persistent’ desktop pool, which can be removed, reset (OS reset), edited (recomposed or refreshed) or rebalanced

Linked clones, persistent desktops and OS maintenance; 1 + 1 + 1 = 1?

Another thought came to mind worth mentioning. In my test I created a desktop pool with the combined technologies of linked clones and persistent desktops. Of course on these desktops, I do have to perform maintenance, as Microsoft hotfixes come out the second Tuesday of the month and who knows what else needs to be updated. Initially I thought I could use the linked clone technology for this; update my master virtual machine with hotfixes, take a new snapshot and link all deployed desktop to the new snapshot. If all is well this will work, however, what happens to my ‘persistent desktops’ if I do that? In fact, all users having made changes to the OS (I chose to allow certain users to install their own applications) lose their OS customizations and their applications.

After linking desktops to a new snapshot, it appears that the only thing that is really persistent about the ‘persistent desktop’ is what is on the user data disk, which contains the ‘documents and settings folder’ and maybe some data, but not the entire installed application the user needed. Ergo, if I want to maintain my OS with hotfixes using linked clone technology or ‘Desktop Recompose’, while at the same time keeping users’ customizations to the OS, I will have to use a tool like SMS/SCCM, Radia or whatever your standard corporate application distribution method is. My question then is: what does ‘Persistent Desktop’ really mean?

I performed one more test to see how intelligent the linked clone snapshotting technology really is when it comes to managing disk space. I started off with a Persistent Desktop:

- System disk: 230 MB

After I logged on as an administrative user, I copied an installation of Eclipse, sized 354 MB, to the System disk of my virtual machine.After the file copy, my System disk looked like this:

- System disk: 607 MB

I decided to delete the Eclipse folder. After deletion, the system disk looked like this:

- System disk: 607 MB

Conclusion: The Eclipse folder doesn’t seem to be deleted and the data is still available in the snapshot.

I decided to copy the exact same Eclipse folder again to the same destination on the system disk, which then looked like this (I also tested another destination; c:\temp, which had the same result):

- System disk: 623 MB

Apparently, some check was done as the linked clone disk reused the data that was marked as ‘deleted’.

After I removed Eclipse again, the system disk looked like this:

- System disk: 640 MB

Now since Eclipse is deleted off disk and the system disk still has the size of 640 MB, which means the data is still there, maybe the snapshot technology is intelligent enough to mark the space as deleted so it can be filled up with other data. I copy some other data to the system disk that is smaller than the size of the data that could be ‘marked for deletion’. After copying a 219 MB folder, the disk looks like this:

- System disk: 852 MB

Conclusions:

1. Providing linked clones to users that have full control to the system, resulting in user initiated changes to the OS like copying data, removing it, etc., will end up in a system disk that eventually has a bigger size than if the OS was provided to the user without the linked cloning technology.
2. If a View Administrator decided to refresh the OS because he added some hotfixes or extra software, all user modifications to the OS are deleted. In fact the System Disk is simply deleted and a new linked clone is generated off the new state of the ‘master image’.
3. What ‘Persistent desktop’ actually means is that the state of a disk provided by a View Administrator is ‘persistent’. A desktop can be made persistent by recomposing or (scheduled) refreshing the deployed linked clones, resulting in exactly the state that a View Administrators expects it to be. From the view of end users using Linked Cloned Desktops, no persistence can actually be guaranteed, because all user actions will be undone by ‘Desktop Refresh’ or ‘Desktop Recompose’.
4. As soon as user modifications to the System Disk need to be persistent, no linked clone technology should be used. Instead, 1-on-1 desktops need to be provided, in which deployment tools like SCCM or Altiris will have to be available to maintain the system.