In this three-part article series, Roland van der Kruk, a freelance consultant in The Netherlands, takes a look at the new features of VMware View 3, as well as best practices learned while doing a deployment for a customer. Part 1 provides information and insight on new features, Part 2 looks at Linked Clones, and Part 3 (this article) will look at special considerations and best practices for deployment.
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
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
- This also means two more things:
- 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...
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:
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
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.
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.
Roland van der Kruk is a freelance consultant in The Netherlands. He currently works with server-based computing and desktop delivery solutions. Roland can be contacted by email at firstname.lastname@example.org or through his website at http://www.sbcprojects.com.