In-Depth

Using Linux Virtual Desktops With VMware Horizon View

It's easier, and works better, than you might think.

• By Tom Fenton
• 01/15/2016

There are many reasons that enterprises may wish to use Linux desktops within a virtual desktop infrastructure (VDI) broker. I outlined five of these in a recent article. Now that all major VDI vendors support Linux desktops, I wondered if using a VDI broker with Linux could significantly help with the entitlement, authentication, provisioning, security and management of Linux desktops over physical Linux desktops. I'll be using Horizon View for this investigation, but most of the information is pertinent to other VDI brokers.

For those new to using VDI, the concept is straightforward: a user uses a client device (laptop, thin client, tablet and so on) to connect to a broker in order to connect to a Linux desktop running as a virtual machine (VM) on a hypervisor. The VM has an agent running inside of it that relays information back to the broker. The broker handles the entitlement of users, the association of users with virtual desktops, and in some cases the provisioning of the virtual desktops. A simple VDI architecture is shown in Figure 1.

In order to investigate VDI running Linux desktops, I set up a VDI environment in my lab. The lab hardware consisted of a Dell R610 (12 CPU cores, 96GB RAM, four 2.5" Micron M500DC SSD drives and two WD 750G Black HDD drives); a 24 port 1GB switch; and various endpoint clients. The virtual infrastructure consisted of a single hypervisor (ESXi 6.1) being managed by vCenter 6 VCSA. I installed VMware Horizon Enterprise 6.2 to create the VDI infrastructure, then created three CentOS 6.7 Linux virtual desktops. All VMware software was under trial licenses.

Horizon View 6.2 allows Linux desktops to be used as virtual desktops. VMware has three licensing options for using Linux desktops with View: Horizon 6 Enterprise Edition, VMware Workspace Suite and View for Linux. For those interested in running only Linux desktops, View for Linux is the least costly option.  

The installation of View took me less than 30 minutes. I've set up View dozens of times and am very familiar with its installation process; those with vSphere experience but new to View should still be able to do this in under an hour.

Next, I created three CentOS 6.7 VMs. View 6.2 supports four Linux distributions: Ubuntu, RHEL, CentOS, and NeoKylin. Supported versions of these distributions can be found in the VMware documentation. Each of the VMs had two vCPUs, 4GB RAM and a 120GB hard drive. I then installed VMware tools and View agent on the VMs. The agent registers the VM with the connection broker.

After creating the Linux VMs, I created a View manual desktop pool (Figure 2) via the View Administrator Web portal. A desktop pool allows for the grouping of virtual desktops for administrative purposes (Figure 2 shows the settings of the desktop pool). Manual desktop pools are required, as automated desktop pools aren't supported with Linux virtual desktops. Automated pools will create the virtual desktop automatically and as required from a template.

Virtual desktops can be accessed on Windows, Linux or Mac OS X OSes machines using either a Web browser or the Horizon client (Figure 3). (Note that zero clients and mobile clients aren't supported at this time.) I tested my virtual desktop using all three supported OSes.

Once the VDI environment was built up and the Linux VMs were created, I wanted to see how easy it was to entitle, authenticate, provision, manage, secure and access Linux desktops being managed by VDI compared to running Linux desktops running on physical hardware. Here’s what I observed for each of these processes.

Entitlement. The ability to authenticate users to access virtual desktops in View is done via Active Directory. Individual users or groups of users can be entitled to access pools of desktops. Desktops in these pools can either be dedicated (persistent) to a single user, or floating. Floating desktops allows any user entitled to a pool to access any desktop in the pool; desktops aren't assigned to a single user. A floating desktop pool is useful if you can decouple the user's persona (user data, settings and so on) from the desktop. Fortunately, Linux has many schemes that allow the decoupling of user data from the desktop on which they currently reside.

Authentication. View with Linux desktops, unlike View with Windows desktops, does not yet support single sign-on (SSO). SSO allows your credentials to be passed from the Horizon client (Figure 4) to the desktop. Linux virtual desktops require you to log on separately to the Linux desktop (Figure 5) after first logging onto the Horizon client.

Provisioning. One of the limitations with using View with Linux Desktops is that currently there is no built-in mechanism to automate the cloning of Linux desktops, nor does it allow View Composer to be used to create and manage storage-efficient "linked" cloned desktops.

To overcome this limitation, VMware and others have come up with scripts to automatically provision desktops in a timely fashion. For example, Michael Webster created a script that provisioned 400 Linux desktops from a template, and registered them with Horizon View in just 11 minutes. If you don’t use a scripted solution, you'll need to manually clone a base image, instantiate the Horizon agent and then add the VM to the desktop pool. Compared to creating physical Linux desktops, where hardware would need to be provisioned and the desktop imaged separately, it's far easier and quicker to provision a virtual desktop.

Management. Virtual desktop hardware is extremely easy to upgrade; you can add CPU cores, RAM, NICs and so on with just a few clicks. Transferring the disk to a faster media, for example, from a slow HDD to a fast SSD, can be done in the background without interrupting the end user via vMotion. vMotion could also be used to evacuate all the virtual desktops on a server or storage array if it's coming off lease or needs to come down for firmware, software or hardware upgrades.

Historically speaking, backups have been troublesome; virtual desktops, however, alleviate much of the hassle as they can be performed at the server level rather than on each individual desktop over the LAN. Backups on physical desktops have been known to cause serious network congestion, but with virtual desktops the backup data in many cases doesn't need to traverse the LAN from physical server to backup media.

Managing the software on a Linux desktop is also simplified by using virtual desktops. Virtual desktops can be accessed from the client, or if needed, directly via the vCenter virtual console. With virtual desktops, gone are the days of running from physical system to physical system to address software issues. Patching physical systems have been known to cause massive network traffic, but with virtual desktops this is mitigated as network traffic is contained locally. 

Security. Many companies choose to go to virtual desktops for security reasons. For example, a virtual desktop simply cannot walk out the door or be left at a restaurant, since it's stored inside a datacenter. Other security concerns that virtual desktops help mitigate are viruses and unauthorized access to desktops. If a system does become compromised, it can be brought down immediately. It's been reported that the majority of data theft is done by internal sources as opposed to external hackers; virtual desktops can minimize this threat by locking them down to prevent storage devices from being attached to them.

Accessibility. Physical Linux systems can be configured to allow remote access via various means; however, these remote access schemes suffer from a lack of security, display optimization and manageability. View supports accessing a virtual desktop via a secure, optimized remote display protocol from either a Web browser (Figure 6) or the View client (Figure 7). At this point, zero clients and mobile clients aren't supported with virtual Linux desktops.

I tested accessing a Linux desktop from a verity of devices running different OSes, and here's what I found.

• Dell Laptop running Windows 8.1. I was able to I was able to access my Linux desktop from both a Web browser and the Horizon client.
• Lenovo X1 Carbon running Windows 7.0. I was able to access my Linux desktop from both a Web browser and the Horizon client.
• Lenovo IdeaCentre Stick 300 PC running Windows 10. I was able to access my Linux desktop from the Web browser. I was unable to install the Horizon client as the Horizon client only supports Windows 10 Enterprise. The Lenovo Stick is a very small PC (100 mm x 38 mm x 15 mm) running an Atom processor with 2GB RAM, 32GB storage, one HDMI and one Micro USB 2.0 port. I wanted to see if a small PC running an Atom processor could be used to access desktops; I found that the performance of this device was on par with the other clients.
• MacBook Pro running OS X 10.10 "Yosemite". I was able to access my Linux desktop from both a Web browser and the Horizon client.
• Physical Linux system running Centos 6.7. I was able to access my Linux desktop from both a Web browser and the Horizon client.   
• Zero client Samsung "Cloud in a Box" (NX-N2). As expected, the Samsung Zero client worked fine with a Windows virtual desktop; but when I tried to access a Linux desktop, I received a "Does not support the requested protocol" message.

Resource utilization. Hypervisors allow for greater utilization of a server’s CPU, memory and storage by running many instances of an operating system on a single physical server. Using common rules of thumb for a task worker, and going off of what I observed in my lab, I should be able to run four VMs per physical core on my server, or 48 virtual desktops (4 x 12) on my Dell R610 server.

However, my R610 only has 96GB RAM, and as I allocated 4GB RAM to each virtual desktop, it would only would support 24 virtual desktops (96/4GB) without overcommitting physical memory. This is still an impressive number for a single 2U server. The 24 desktops would consume about 3TB of storage.

In reality, however, as the virtual disks were thin provisioned, they would use only as much space as required to store the user’s data: probably only 50 percent to 75 percent of that amount. Storage could also be further reduced if a storage array was used that supported deduplication, as the majority of the data on desktops is redundant.

One of the most noticeable benefits I found after working with VDI Linux virtual desktops was that they could be accessed from any location, with interconnectivity from a plethora of different machines. I was comforted by the fact that the data itself was securely stored in my home lab.

With this access I would be able to install new software, or observe and correct issues that users were having with their desktops. If a user was hardware-constrained, their virtual hardware could be reconfigured in seconds.

VMware View Linux desktops do not yet support all the features of Windows desktops, including support for linked clones, single sign-on (SSO) and support for mobile device and Zero client access. I'm confident these features will come with time, but compared to physical desktops they are far more secure, manageable and accessible.