Introduction to Virtual Desktops
Video Content [TBA]
Version: Horizon View 5.1
VDI is essentially the same as Terminal Services (TS) or Citrix XenApp (formerly MetaFrame/Presentation Server). That is to say, you provide a desktop to the user via a “thin” protocol. The difference between server-based computing and virtual desktops is that rather than having many users connected to one shared TS or Citrix Desktop running a server OS, users connect to their own personal desktop running a desktop OS. By virtue of VDI making use of a non-shared desktop OS, application compatibility issues that can plague a TS environment are almost completely mitigated. A variety of protocols exist to deliver the remote desktop, including the older legacy Microsoft RDP, and the newer Teradici PCoIP (used in VMware View), Citrix HDX and Microsoft RemoteFX protocols. These new protocols attempt to address some of the persistent graphics rendering limitations of the older display protocols. The advantages of VDI are many, but its key advantages beyond the benefits of Thin Client Computing generally lie in remedying some of the limitations presented by the shared desktop approach of TS and Citrix XenApp:
Advantages of Virtual Desktops
- One user’s activity does not directly affect the performance of other users. Each user is limited to the resources within their VM
- Applications install natively to the Windows environment. There is no need for complicated installation routines and validation to make applications work in an environment for which they were never actually designed. However, many people also like to complement their virtual desktop environment with a virtual application solution like VMware’s ThinApp or Microsoft’s App-V
- Desktop Hardening. The process of locking down the desktop - whilst desirable in VDI - is not mandatory. In TS & Citrix XenApp you absolutely must lock down the desktop to stop one user affecting the stability of the environment for other users using the shared desktop
- VDI allows you to leverage your corporate license agreement with Microsoft at no additional charge depending on if you have a Software Assurance (SA) agreement in place with Microsoft – without it the fee is around $100 per seat, whereas each Citrix XenApp end-user connection requires a license from Citrix. Indeed, Microsoft went so far as to introduce a specific licensing model currently called the VECD (Vista Enterprise Centralized Desktop) program to promote the use of Windows as the operating system in the virtual desktop. This is has been since superseded by a new model called VDA. It’s by no means mandatory that you must use Windows as the guest operating system in a VDI project. You could use a Linux desktop distribution if you prefer it or your needs require it. This said few VDI environments run with just the virtualization layer and a virtual desktop on its own. Nine times out of ten there will be some type of VDI Broker server that will also need licensing!
- VDI can be coupled with other application virtualization tools such as Microsoft’s App-V or VMware’s ThinApp to reduce the footprint of the virtual desktop (because less is installed to Windows) and also allow for advanced features such as being able to run many different versions of the same application (flavours of Microsoft Word and Adobe Acrobat, for instance) on the same virtual desktop
- Features such as VMware View’s Local Mode Desktop that allow an end-user to take a copy of the virtual desktop from the vSphere host and make it available on their PC or Laptop even when they are not connected to the corporate network. * Local Mode Desktop uses deltas to make sure only changes are synchronized back to the server copy of the desktop, and a Time to Live (TTL) value that allows for the offline desktop to work only for a limited period. In years to come these * Local Mode Desktops might be available on a possible client-based hypervisor as well
- VMware View 3 introduced View Composer to enable the linked clone feature. This allows for one single master VM from which many virtual desktops can be created (the linked clone). These linked clones contain only the changes the user makes during the virtual desktop session and, as such, massively reduce the disk space required to run virtual desktops. However, linked clones can introduce other complications around storage capacity management and performance.
Disadvantages of Virtual Desktops
- Printing is a huge challenge in the world of thin-client computing. By far the biggest challenge is the amount of bandwidth used to send a print job from the remote datacenter back to the end-user’s physical printer. It’s quite common to see Microsoft PowerPoint print jobs balloon in size to hundreds of megabytes. Some thin-client vendors have their own solution using some kind of universal PCL printer drivers. Some organizations prefer to buy in a third-party printing solution such as ThinPrint or UniPrint. In View 3, VMware acquired a license for the core ThinPrint product that they call “Virtual Printing”. This licensed version of ThinPrint address most printing needs
- Storage can create some serious challenges in a VDI environment. However, with the introduction of de-duplication technology from storage vendors such as NetApp, and the introduction of thin provisioned virtual disks in vSphere 4, this becomes less significant. As we have already mentioned, VMware had effectively created a kind of built-in de-duplication process with View Composer. If you combine thin provisioning from your storage vendor with thin-provisioning from VMware together with the linked clones feature, you are able to reduce the disk foot print of your virtual desktop environment. Please keep in mind that all these technologies can create some additional requirements for the performance your storage solution would need to deliver. It’s worth stating that for modest VDI solutions local storage is a viable option, but remember that storing a VM on local storage means you cannot use a lot of VMware features that need shared storage like HA, DRS and DPM.
How most VDI Systems Work
Despite the variety of solutions that now crowd the virtual desktop space, as you might expect, they all work in very much the same way and offer very similar features. Most will have a broker component, which acts as an intermediary between the user and their virtual desktop. The job of the broker is to provide a logon process after which the end user can select their desktop. Very often this connection will be based around a certificates-based SSL connection. This broker will also integrate with the management system to allow you to create pools (groups) of desktops for different purposes – a Sales Desktop pool and an Accounts Desktop pool for example. It will also integrate with a directory service for example Active Directory to allow you to allocate the correct virtual desktop to the user.
At the end user’s side, they can either use a webpage to log in or use a dedicated client. Frequently, the full client will offer a higher level of features to the end user than an ActiveX or Java client can provide. There will normally be some kind of agent installed in the virtual desktop that allows the user to connect to the virtual machine. Frequently, this agent will support advanced features such as two-factor authentication with technologies such as RSA’s Secured, and the ability to redirect USB connections between the virtual desktop and the connecting device. This allows the user to login with very high security and, for example, still use an USB-hosted printer on their desk.
For “Dilbert” or call centre-style users, you might even want to go so far as replacing the physical desktop PC with a thin client sometimes referred to as a dumb terminal (maybe they should be called Smart Terminals?) which only offers a screen, keyboard and mouse interface to the virtual desktop. However, advanced variants of these devices can also include 3d graphics cards which enable significantly improved local rendering of complex remote desktops. There are two main types of dumb terminals; the first type has some kind of low-level operating system embedded in the client such as Windows CE, Windows XP Embedded or Linux. These clients can be flashed with a new operating system remotely. The other type of dumb terminal is the Zero Client - they are very similar to the first type, but Zero Clients have no operating system, but just firmware to manage.
There are many, many of these devices available. It’s well worth asking an OEM Vendor for samples of their devices so you can test them against your VDI environment since they vary massively in quality, functionality and reliability. To be brutally honest some can be rubbish and more trouble than they are worth. Some popular vendors of smart terminals and zero clients include:
- Devon IT
- Oracle Sun Ray
- OEMs – All the major OEMs such as HP, Dell, and HP have some kind of Thin-Client Device
Horizon View Architecture
VMware Horizon View (formally called VMware View and VMware Virtual Desktop Manager – VDM) ships as different .exe files when you download it from VMware’s website
- Connection Server (includes Connection, Replica, Security and Transfer Server roles) – the broker
- Composer – the component which builds Linked Clones
- Agent – installs in VM OS to provide additional VDI features
- Client – installs in end user OS
- Client (with Local Mode desktop support) – if available, enables Local Mode (aka offline) VDI
Since VMware View 4.5, these binaries are available in 32-bit and 64-bit formats for both the client and server components. In this guide we have decided to use the 64-bit for the server components. Since Windows 2008 is the last 32-bit operating system from Microsoft, we have made the decision to move over to 64-bit in our environment sometime ago. As of version 4.6 if you wish to use the View PCoIP “Secure Gateway” functionality you must use Windows Servers 2008 R2.
The Connection Server is VMware’s term for a broker, and it actually comes as two types of server - a Security Server that can safely be placed in a DMZ, and the Connection Server that sits inside your private network and requires access to your Active Directory environment. The Security Server and Connection Server are linked together to allow seamless and secure traversal of your firewall. Both Connection and Security Server roles encrypt the network link between the client and virtual desktop – essentially wrapping a SSL tunnel around the relatively insecure RDP communication. However, only the Security server is deemed safe to be placed in a DMZ as it does not need to be a member of your Windows domain, and it can be hardened using standard procedures such as disabling unwanted Windows services. In VMware View 4.5, a new Transfer Server role was introduced which is used to manage and accelerate the download of Local Mode virtual desktops.
Below is a pretty typical diagram of the View 5.X infrastructure. It’s missing some components such as the Security Server and the Transfer Server roles, so it is very much a LAN representation of the infrastructure. The main thing to say from a network perspective is that the Connection Server will need IP visibility of your client devices and the vCenter server in order to broker connections to your centralized desktops. Additionally, the Connection Server does need to be added into your Active Directory domain structure in order to correctly authenticate end users.
All in all, the experience for the end user is like sitting on a trusted network at the corporate office, but remotely. The VMware Composer is a software component that enables the functionality of creating a Master virtual desktop from which all end-user virtual desktops are created. Changes to this Master virtual desktop may be proliferated to all its associated virtual machines. It is possible to have more than one Connection Server and Security Server for fault tolerance. VMware uses Microsoft Active Directory Lightweight Directory Service (AD LDS) as the method of making sure that all the connection servers share the same configuration data by replicating this configuration information in a multiple-master model that is exactly like Microsoft’s Active Directory service. VMware use their own instance of AD LDS to store the configuration information and does not make any changes to your Active Directory schema.
However, VMware do not currently offer a method to balance the load dynamically across the different Connection Servers or Security Servers. This means you will have to invest in some method that ensures an even distribution of user connections across them. For example, in the old Virtual Desktop Manager (VDM) course, we have used the free load-balancing virtual appliance called Hercules as a load balancer. In this guide, we are going to use Microsoft’s Network Load-Balancing (NLB) and F5's BIG IP solution. However, its important to realise there are many different solutions on the market that will offer this functionality for you.
We have been working with server side computing for some time and understand that it is definitely not a one horse race when it comes to virtual desktops, however with VMware's latest release of View the functional differences between vendors products is becoming a lot less. Server side computing has been around for some time but VDI offers a number of significant benefits over a traditional server-based computing solution. Your VDI solution is going to be made up of a lot of different components and it is important to consider all the various elements prior to starting to design your solution. Some elements such as load balancing and thin clients may require additional third party purchases for your environment. As you read through the chapters of this book we will guide you through the various elements that you need to consider all the way from design concepts through to installing View 5 and to finally what you can expect to see coming from VMware in the future, and lots more.