Citrix edges VMware, Microsoft in VDI face-off

BYOD adds complexity to hosted VDI implementations

1 2 3 Page 2
Page 2 of 3

Like Oracle VDI, Horizon View could cache memory and storage among desktops and could be optimized to help survive an access storm. We had insufficient resources to characterize the duty cycle of logon accesses that makes this useful when deployed, but we had a strong sense that much detail was given to optimizing storage.

The downsides are mostly administrative. We changed our Horizon View server at mid-test from the lab to our NOC at nFrame. In doing so, IP addresses changed. This started a cascade of difficulties. A server certificate disappeared, causing endless head scratching and the revelation that many VMware Horizon View error messages are vastly inarticulate. Horizon View wants a log file kept in SQL Server or other compatible database -- and not the one used for optional Horizon View Composer.

Lacking that, it's difficult to keep track of events, and coupled with inarticulate error messages, we spent days of downtime researching problems. This is why we suggest 1) using a working CA infrastructure even during a trial 2) have a thorough understanding of what ports are needed on what host to communicate with what. If you're only hosting Windows, and already love VMware, this is the ticket.

If we hadn't seen the forensic dramas, we'd have given Horizon View a slightly higher rating, and we acknowledge that most large organizations will never see the issues and circumstances we found. Horizon View had stellar customization possibilities (more so with optional Composer) and a very good client experience that was consistent on any of the devices we tried, and many are supported. We believe it could grow well for organizations needing a large VDI infrastructure. We were dismayed at its Windows-only VDI hosts, and have scar tissue and bruises from small attempts to change settings. Nonetheless, after a sophisticated installation, Horizon View works -- it's very lovely and rich and extensible.

vdi

Oracle VDI

Oracle VDI is a construction set with two main components. There's Oracle VDI atop x64 Solaris or Oracle Linux, then a working hypervisor infrastructure one chooses to connect VM instances. The served instances could be from Oracle, Microsoft or from other sources -- but not more than one variety. Installation and integration isn't really “automatic” and there are no real “wizards”.  

As tested, Oracle VDI is aimed at organizations wanting a multi-tenant feel towards VDI hosting. The Solaris underpinnings we tested are well-poised towards multi-tenant partitioning philosophies. Access devices supported include Windows, Mac, Linux, iOS, and Android. Because of some basic limitations, it's good only for organizations that either employ VPNs, or can assure stateless firewalls at both the host site and client site. Oh, and it's not captive to Windows hosted VDI images.

We used Oracle VDI with Oracle's VirtualBox 4.2, although there is Oracle VDI support for most major hypervisors, like VMware vCenter or Microsoft Hyper-V. The Oracle VDI offerings works on Oracle (ostensibly) Unbreakable Linux kernels, Solaris 10 or Solaris 11. We opted to install initially on Oracle Solaris 10, but were offered Oracle 11 and chose Solaris 11.

Choosing Solaris 11 as a host platform was possibly a procedural mistake and slowed us down. Solaris 11 (we used 11.1) is very much different from Solaris 10, and different from mainstream BSD and Linux. Solaris 11 uses ZFS, which is a highly sophisticated filing system that can in turn, be allocated as a substrate for other filing system resources.

Oddly, we couldn't use external iSCSI storage -- a current limitation of Oracle VDI on Solaris 11. Traditional network and configuration management has changed, however, from the containers-based methodology introduced in Solaris 10, into a profile and location-based infrastructure that is poised more towards multi-tenant uses. The changes are jarring and had us referring to Oracle's disjointed and occasionally incorrect documents frequently. Solaris's biggest enemy is its own modularity.

Installation of Oracle 11 can be pre-set by installing a local version of the OS along with pre-configured settings to allow a NOC-deployed host to start up and smile at you. Otherwise, it's remote configuration through ssh into a NOC install. We strongly suggest that potential users of Oracle VDI have a pre-existing support relationship with Oracle, so that repositories are easily available as well.

If not, installers will need to download an eye-popping 7GB of update and app repository from Oracle, assemble it externally, then send it to the server and make its resources available. There were days when we felt like beta testers because we don't have an Oracle support contract. Installation can take place on a single quad-core Intel host with a minimum of 8GB of memory and 100GB of disk -- but you'll need much more to host VM sessions unless you take them from Hyper-V or VMware. Oracle VDI must be initially installed with the firewall off, so we installed it in an isolated network, then later put it onto a production network.

Once installed, we had plentiful options in terms of partitioning resources on Solaris 11.1/SunOS 5.6., and in the end, we allocated most of our test Lenovo ThinkServer for use of VM sessions. After a VDI-install program was run (two minutes) we installed the Solaris edition of VirtualBox 4.2. We also had desktop virtualization options (not tested) that included brokering RDP connections to hosted VMs on VMware, Microsoft's Hyper-V, the Sun Ray Kiosk system, or Microsoft RDP server-farms -- or a generic IP address. All are accessed under the aegis of “providers” where the Oracle VDI app serves as a connection broker between clients and target VDI host infrastructure.

We decided to start simple, with VirtualBox-hosted Windows 8, Windows 7 and LinuxMint 14 instances. We would then access these instances with our many client devices, including an iPad Mini, Toshiba Android and Excite 10 tablet.

It's possible to integrate Solaris 11 with Microsoft Active Directory or LDAP/OpenLDAP directory services for authentication proxy. We used Active Directory for proxy authentication via Kerberos, which took some experimentation, but eventually worked. Kerberos requires time synching, which we discovered we lacked, then fixed. We could also scramble the port used for administrative and user access, which we liked. While we liked the fact that Solaris 11 can be made highly secure and suits multi-tenant installations, we warn that moderately strong Solaris 11-specific skills are needed to perform a clean installation; civilians or even moderately skilled Linux admins will get bruised.

We installed the connection broker, and then pools of persistent and non-persistent desktops. We could choose from Oracle VDI Desktop client templates focused exclusively on Windows XP+ editions, or Microsoft's sysprep -- which is familiar to many -- to pre-load Windows desktops for VDI reuse -- or use a manual installation method for Windows/non-Windows VDI hosts.

We could also import VMs from VMware as well. As things need to be revision synched between VirtualBox and VMware, we don't recommend this without a trial phase. Remember: this is a construction set. VirtualBox-hosted VMs, if they're compatible with Oracle's VirtualBoxRDP/VRDP, offered us more responsiveness and local device options, like USB and sound, than the other protocol Oracle VDI supported, generic Microsoft RDP. We strongly suggest using VRDP-hosted sessions where permitted.

Oracle VDI can be optimized for resource sharing; memory can be shared among desktops to prevent startup-storms from occurring when templates need to be retrieved from disk in order to make non-persistent virtualized desktops. The client experiences, in terms of how it looked on BYODs, was very good, but with Oracle's VRDP, startup is slow. We were happy with the response over broadband, although it seemed noticeably slower than Citrix Receiver clients and Horizon View PCoIP clients.

We then found a problem: the Oracle VDI Client App wanted to hear a UDP reply from the Oracle VDI server. The device client app will wait forever for this reply. And many Comcast routers, home or small business, and many others, shut off inbound UDP by default. This means that Oracle's VDI almost mandates a working organizational VPN, along with the client software to run them on the chosen client device. Lacking that, you won't be able to logon from many public resources unless you can unblock UDP-returns.

We obtained the VirtualBox remote client from the Google Play Store and the iOS client from the iTunes Store. Other clients are available through Oracle web resources. On the VDI hosted VMs, the clients were as sharp and useful as VMware's, just a noticeable amount slower to initially load-up and slower for rapid screen deltas.

Oracle's VDI is seemingly endlessly extensible, but doesn't have the client-side pizazz and incredible device compatibility of either Citrix VDI-in-a-Box, or the dogged security and PCoIP sauce that VMware's Horizon View offers. However, unlike each of these, it's not chained to Microsoft's Windows, but does a respectable job with Windows. Only tenacious Unix/Linux/BSD-driven administrators have the slightest chance of an installation that won't require Rogaine from tearing one's hair out. But that's why you opted for Oracle Support, right?

Microsoft Windows 2012 Remote Desktop Services

Microsoft's RDS is somewhat simple, and implements a connection brokerage to either discrete Windows VM instances hosted on Hyper-V3, or desktop sessions on Windows Server instances. Unlike the old, now obsolete “terminal services/TS” in prior Windows Server editions, RDS mandates a working Active Directory infrastructure, and this precludes non-Windows clients, so far as we can find. VDI-in-a-Box and Oracle VDI don't require Active Directory, but RDS and Horizon View do.

There are two separate services, Remote Desktops/RD (which are server-hosted sessions that generate a desktop that can be accessed by internal/external clients), and VDI-hosted sessions from instances hosted on Hyper-V. Either type of session is hosted under the constraints of Active Directory policies and security underpinnings, and either type may be a persistent or non-persistent session. Microsoft requires one of two types of CALs, user and CAL. Users have the choice of a number of devices to VDI sessions. CALs allow promiscuous use, but the costs aren't much different, and each cost is for a “perpetual license,” according to a Microsoft spokesperson. Having Microsoft's Software Assurance may assuage or mitigate these costs depending on your relationship with Microsoft.

It's possible to implement an external connection to access hosted sessions, say from a coffee shop; this requires the RDS CAL External Connector Option, which is another, separate license.

The good news is that once licensing issues are sorted, those familiar with Windows 2012 will be able to follow simple instructions to achieve either type of session -- internally or Hyper-V hosted sessions. We chose to install the appropriate roles, which have two branches, one for an RD gateway to Hyper-V resident hosts, or the other direction, Windows 2012 server-hosted sessions. We also needed to install a server role, Network Policy Services.

Working SSL certificates are required. Microsoft's own certificate authority is adequate, but others that support TLS 1.0 and are built correctly are fine. We used Microsoft's certificate authority. An RD Gateway must also talk with a Network Policy Server, which contains the Central Remote Desktop Policy Access Store/database; a clear path to it must exist, as it's accessed to vet logons. No path, no logon.

Support for BYOD-style clients directly from Microsoft is very weak, although much can be obtained from third parties to work with Microsoft's Remote Desktop Protocol 8, which works on Windows user-device instances. Citrix can play here, but in terms of Microsoft-supported client devices, there are but a handful.

The handful, including the Windows 7 and 8 devices (an older version of RDP is still available for those using Windows XP SP2+) looked as though we were using a native connection. Graphics were fast, and GPU support is available for those needing extreme graphics response, but this wasn't tested.

There is no real heterogeneity in Microsoft's offering; it's Windows or the third-party highway. What were once Terminal Services appear to be slowly deprecated. Our RDS server-hosted sessions were easily accessible and a plainly generic experience. Hosted VDI instances were customizable and crystal clear and finger-snapping fast, and the overall installation was both easy and predictable, but we're becoming very used to Windows 2012 server. If you're a “Windows shop,” and you're not going to tax much and sneeze when you hear iOS or Android, stop here.

Ericom PowerTerm WebConnect 5.8

The Ericom PowerTerm WebConnect (PTWC) product is a gateway system for client devices and hosted VM resources. Both the client devices and hosted VMs are vastly heterogeneous, perhaps in the extreme. There are two likely components, a gateway server that is recommended to be hosted in a DMZ zone behind a firewall, with a single port facing the world -- SSL on Port 443. In turn, the gateway server connects through secondary firewalls to internal host resources that include Ericom's AccessNow Server, Ericom Blaze Server, Terminal Services (if desired) and the cabal of user-configured host resource infrastructure that is built and hosted outside of the scope of Ericom's control.

1 2 3 Page 2
Page 2 of 3
Now read: Getting grounded in IoT