In-Depth

Using Linux Virtual Desktops With VMware Horizon View

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

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.

[Click on image for larger view.] Figure 1. A simple VDI architecture.

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.

[Click on image for larger view.] Figure 2. Desktop settings.

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.

[Click on image for larger view.] Figure 3. Client access options.

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.

[Click on image for larger view.] Figure 4. Logging into View via Windows.

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.

[Click on image for larger view.] Figure 5. The Linux-based login window.

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.