View 4.5 Availability and Enhancements

After a series of delays, communication failures and marketing mis-steps that left many customers frustrated and confused, VMware finally shipped View 4.5 on September 9th.

Anticipating the formal announcement was a widely leaked report that View 4.5 would ship without Virtual Profiles, the user profile management solution that VMware OEMed from RTO Software in fall 2009.  VMware finally confirmed that the leak was correct on the first day of VMworld 2010, but even then held back from announcing its interim solution until after the formal product launch. Then rather than simply offer View customers a copy of Virtual Profiles as a standalone product, VMware chose instead to partner with Liquidware Labs to enable them to offer Liquidware Labs’ ProfileUnity to View customers at a substantial discount.  While VMware’s position is that Virtual Profiles will ship with View 4.5 at some point in the future, the decision to offer ProfileUnity instead did nothing to address the concerns of potential customers, especially those who might finish up paying twice for a profile management system. The only good news for View customers is that ProfileUnity’s agent-less and database-less architecture should make the future migration to Virtual Profiles a simple matter when the time comes to move.

Profile related disappointments aside, View 4.5 does include several notable enhancements over the 4.0 release.  System scalability has improved significantly beyond View 4.0 with View 4.5 now supporting up to 10,000 desktops per management domain bringing it into line with the size of deployment supported by XenDesktop. At the same time support for the number of VMs per CPU core has been doubled fro 8 to 16 with vSphere 4.1. This change to vSphere scalability is unlikely to make a significant impact at present, 1/16th of a core is not sufficient to run most desktop workloads at present, but in the longer term it may go some way to reducing the cost of delivering View if servers with large amount of memory ever become truly affordable. Also new in View 4.5 and coincidentally also recently introduced to XenDesktop 4.0 are two new features that are essential to large enterprise environments; role based access controls that allow delegation of certain administrative tasks to separate groups of administrators, and administrative action logging and auditing.

View 4.5’s one feature that provides notable distinction between it and Citrix XenDesktop is View’s ability to operate in “Local Mode” by downloading a virtual desktop from the data center and relocating it to a local system such as a laptop. Local Mode was previously offered an experimental feature in View 4.0 where it was referred to as “Off-line Desktop”.  In addition to the name change, VMware has made some significant improvements to View 4.5’s Local Mode.  The transfer process from data center to desktop and back has been optimized by eliminating the need to ship the Windows page file and any unallocated memory blocks. Further improvements to the virtual desktop transfer process have been achieved by reducing data block size from 128KB to 4KB to improve granularity and reduce the amount of data transferred. VMware has also improved the data transfer protocol used by introducing a compression and de-duplication engine to further reduce the amount of data that has to be transferred to move a View desktop from data center to desktop and ship any changes back again.

Local Mode still requires further work for it to be a complete solution. Support for ThinApp packages is not provided for Local Mode desktops, and even though VMware has a mature and capable type II hypervisor for Apple’s OS X platform, Local Mode is only available for Windows hosts at present. This second issue may well just be a matter of prioritizing support for Windows above that of OS X, but there are still other concerns that need to be addressed. The process of rolling-back changes made to the local copy of a View desktop and copying changes made to the local desktop up to the server hosted virtual desktop (Checking-in in VMware parlance) can be time consuming and access to the Local Mode desktop is barred during both processes.  VMware also appears to have made several questionable decisions in designing Local Mode that will limit it’s usefulness in some situations. A desktop running in local mode  cannot access its host CD-ROM drive from within the View desktop, nor is it possible to copy and paste from the host system to the View desktop. VMware claim that these decisions were made for “security reasons”, but given the ease with which it is possible to circumvent both measures it is hard to take that claim at face value.  On the plus side, VMware and Teradici have made improvements to the PCoIP remote presentation protocol aimed at addressing criticism of its WAN performance.  PCoIP now has an in-built WAN performance monitoring capability that can assist in tuning PCoIP behavior to address changes in WAN error rates and available bandwidth. Further testing is required to determine the impact of these changes.

A less notable is the change to the default PCoIP TCP and UDP port numbers from 50002 to 4172 following the Internet Assigned Numbers Authority’s (IANA) decision to assign port 4172 to Teradici as its official port number moving forward. While existing customers will not need to take any immediate action to migrate their View environments to the new port numbers, it is something that will need to be addressed at some point and it is unfortunate that it has taken this long for Teradici to obtain its IANA assigned port numbers.

One facet that has not changed is the continued lack of support for PCoIP in the View Security Server.  While it is unlikely that any organization would not have a some sort of SSL or IPSec VPN solution in place.  The additional complexity of tunneling UPD based PCoIP through a TCP based VPN connection and the lower level of security afforded by the inability to manage access control listes with the same degree of granularity that a protocol specific secure gateway affords are both significant drawbacks for organizations requiring the highest level of security.  It also has to be noted that using a VPN gateway to compress and encrypt an already compressed encrypted protocol is both inefficient and wasteful.

So how do these latest changes affect the market? Right now that is hard to judge. Certainly View 4.5 represents a significant step forwards for VMware, and with this update it should be able to compete with Citrix in the large enterprise space, even if it that competition is restricted to the simpler end of the spectrum. View 4.5 Local Mode is VMware’s wild card here. View’s success is still by no means assured and if the idea of a type II client hypervisor hosting a managed guest OS takes root we are just as likely to see this breeding success for companies like Virtual Computer, Moka Five, Ringcube and Wanova, who have already embraced their own desktop virtualization  solutions that function without the need for a massive supporting infrastructure within each data center. VMware’s focus upon View to the exclusion of the heterogeneous desktop also plays into the hands of desktop management vendors like AppSense and RES whose products support View, Citrix XenApp, Citrix XenDesktop, and the huge installed base of fat client desktops.