It’s Time To Reconsider My Thoughts on GPUs in VDI…

Last year, I wrote that it was too early to consider GPUs for general VDI use and that they  should be reserved only for VDI use cases where they are absolutely required.  There were a number of reasons for this including user density per GPU, lack of monitoring and vMotion, and economics.  That lead to a Frontline Chatter podcast discussing this topic in more depth with industry expert Thomas Poppelgaard.

When I wrote that post, I said that there would be a day when GPUs would make sense for all VDI deployments.  That day is coming soon.  There is a killer app that will greatly benefit all users (in certain cases) who have access to a GPU.

Last week, I got to spend some time out at NVIDIA’s Headquarters in Santa Clara taking part in NVIDIA GRID Days.  GRID Days was a two day event interacting with the senior management of NVIDIA’s GRID product line along with briefings on the current and future technology in GRID.

Disclosure: NVIDIA paid for my travel, lodging, and some of my meals while I was out in Santa Clara.  This has not influenced the content of this post.

The killer app that will drive GPU adoption in VDI environments is Blast Extreme.  Blast Extreme is the new protocol being introduced in VMware Horizon 7 that utilizes H.264 as the codec for the desktop experience.  The benefit of using H.264 over other codecs is that many devices include hardware for encoding and decoding H.264 streams.  This includes almost every video card made in the last decade.

So what does this have to do with VDI?

When a user is logged into a virtual desktop or is using a published application on an RDSH server, the desktop and applications that they’re interacting with are being rendered, captured, encoded, or converted into a stream of data, and then transported over the network to the client.  Normally, this encoding happens in software and uses CPU cycles.  (PCoIP has hardware offload in the form of APEX cards, but these only handle the encoding phase, rendering happens somewhere else…

When GPUs are available to virtual desktops or RDSH/XenApp servers, the rendering and encoding tasks can be pushed into the GPU where dedicated and optimized hardware can take over these tasks.  This reduces the amount of CPU overhead on each desktop, and it can lead to snappier user experience.  NVIDIA’s testing has also shown that Blast Extreme with GPU offload uses less bandwidth and has lower latency compared to PCoIP.

Note: These aren’t my numbers, and I haven’t had a chance to validate these finding in my lab.  When Horizon 7 is released, I plan to do similar testing of my own comparing PCoIP and Blast Extreme in both LAN and WAN environment.

If I use Blast Extreme, and I install GRID cards in my hosts, I gain two tangible user experience benefits.  Users now have access to a GPU, which many applications, especially Microsoft Office and most web browsers, tap into for processing and rendering.  And they gain the benefits of using that same GPU to encode the H.264 streams that Blast Extreme uses, potentially lowering the bandwidth and latency of their session.  This, overall, translates into significant improvements in their virtual desktop and published applications experience*.

Many of the limitations of vGPU still exist.  There is no vMotion support, and performance analytics are not fully exposed to the guest OS.  But density has improved significantly with the new M6 and M60 cards.  So while it may not be cost effective to retrofit GPUs into existing Horizon deployments, GPUs are now worth considering for new Horizon 7 deployments.

*Caveat: If users are on a high latency network connection, or if the connection has a lot of contention, you may have different results.

What’s New – Horizon 7.0

(Edit: Updated to include a Blast Extreme feature I missed.)

Last week, VMware announced App Volumes 3.0.  It was a taste of the bigger announcements to come in today’s Digital Enterprise event.  And they have a huge announcement.  Just a few short months after unveiling Horizon 6.2, VMware has managed to put together another major Horizon release.  Horizon 7.0 brings some significant enhancements and new features to the end-user computing space, including one long awaiting feature.

Before I talk about the new features, I highly recommend that you register for VMware’s Digital Enterprise event if you have not done so yet.  They will be covering a lot of the features of the new Horizon Suite offerings in the webinar.  You can register are http://www.vmware.com/digitalenterprise?src=sc_569fec388f2c9&cid=70134000000Nz2D.

So without further ado, let’s talk about Horizon 7’s new features.

Instant Clones

Instant Clones were debutted during the Day 2 Keynote at VMworld 2014.  After receiving a lot of hype as the future of desktop provisioning, they kind of faded into the background for a while.  I’m pleased to announce that Horizon 7 will feature Instant Clones as a new desktop provisioning method.

Instant Clones utilize VMware’s vmFork technology to rapidly provision desktop virtual machines from a running and quiesced parent virtual desktop.  Instant clones share both the memory and the disk of the parent virtual machine, and this technology can provide customized and domain joined desktops quickly as they are needed.  These desktops are destroyed when the user logs off, and if a new desktop is needed, it will be cloned from the parent when requested by a user.  Instant clones also enable administrators to create elastic pools that can expand or shrink the number of available desktops based on demand.

Although they might not be suited for all use cases, there are a couple of benefits to using instant clones over linked clones.  These are:

  • Faster provisioning – Instant Clones provision in seconds compared to minutes for linked clones
  • No Boot Storms – The parent desktop is powered on, and all instant clones are created in a powered-on state
  • Simplified Administration – No need to perform refresh or recompose operations to maintain desktops.
  • No need to use View Composer

Although instant clones were not available as a feature in Horizon 6.2, it was possible to test out some of the concepts behind the technology using the PowerCLI extensions fling.  Although I can’t validate all of the points above, my experiences after playing with the fling show that provisioning is significantly faster and boot storms are avoided.

There are some limitations to instant clones in this release.  These limitations may preclude them from being used in some environments today.  These limitations are:

  • RDSH servers are not currently supported
  • Floating desktop pools only.  No support for dedicated assignment pools.
  • 2000 desktops maximum
  • Single vCenter and single vLAN only
  • Limited 3D support – no support for vGPU or vDGA, limited support for sVGA.
  • VSAN or VMFS datastores only.  NFS is not supported.

Desktop personalization for instant clones is handled using App Volumes User Writable drives and UEM.

Blast Extreme

VMware introduced HTML5 desktop access using the Blast protocol in Horizon 5.2 back in 2013.  This provided another method for accessing virtual desktops and, later, published applications.  But it had a few deficiencies as well – it used port 8443, was feature limited compared to PCoIP, and was not very bandwidth efficient.

The latest version of Horizon adds a new protocol for desktop access – Blast Extreme.  Blast Extreme is a new protocol that is built to provide better multimedia experiences while using less bandwidth to deliver the content.  It is optimized for mobile devices and can provide better battery life compared to the existing Horizon protocols.

image

Most importantly, Blast Extreme has feature parity with PCoIP.  It supports all of the options and features available today including client drive redirection, USB, unified communications, and local printing.

Unlike the original Blast, Blast Extreme is not strictly a web-only protocol.  It can be used with the new Windows, MacOS, Linux and mobile device clients, and it works over port the standard HTTPS port.  This simplifies access and allows users to access it in many locations where ports 8443 and 8172 are blocked.

Blast Extreme is a dual-stack protocol.  That means that it will work over both TCP and UDP.  UDP is the preferred communications method, but if that is not available, it will fall back to TCP-based connections.

Smart Policies

What if your use case calls for disabling copy and paste or local printing when uses log in from home?  Or what if you want to apply a different PCoIP profile based on the branch office users are connecting to?  In previous versions of Horizon, this would require a different pool for each use case with configurations handled either in the base image or Group Policy.  This could be cumbersome to set up and administer.

Horizon 7 introduces Smart Policies.  Smart policies utilize the UEM console to create a set of policies to control the desktop behavior based on a number of factors including the groups that the user is a member of and location, and they are evaluated and applied whenever a user logs in or reconnects.  Smart policies can control a number of capabilities of the desktop including client drive redirection, Clipboard redirection, and printing, and they can also control or restrict which applications can be run.

Enhanced 3D Support

Horizon 6.1 introduced vGPU and improved the support for workloads that require 3D acceleration.  vGPU is limited, however, to NVIDIA GRID GPUs.

Horizon 7 includes expanded support for 3D graphics acceleration, and customers are no longer restricted to NVIDIA.  AMD S7150 series cards are supported in a multi-user vDGA configuration that appears to be very similar to vGPU.  Intel Iris Pro GPUs are also supported for vDGA on a 1:1 basis.

Cloud Pod Architecture

Cloud Pod Architecture has been expanded to support 10 Horizon pods in four sites.  This enables up to 50,000 user sessions.

Entitlement support has also been expanded – home site assignment can be set for nested AD security groups.

Other enhancements include improved failover support to automatically redirect users to available resources in other sites if they are not available in the preferred site and full integration with vIDM.

Other Enhancements

Other enhancements in Horizon 7 include:

  • Unified Management Console for App Volumes, UEM, and monitoring.  The new management console also includes a REST API to support automating management tasks.
  • A new SSO service that integrates vIDM, Horizon, Active Directory, and a certificate authority.
  • Improvements to the Access Point appliance.
  • Improved printer performance
  • Scanner and Serial redirection support for Windows 10
  • URL Content redirection
  • Flash Redirection (Tech Preview)
  • Scaled Resolution for Windows Clients with high DPI displays
  • HTML Access 4.0 – Supports Linux, Safari on IOS, and F5 APM

Thoughts

Horizon 7 provides another leap in Horizon’s capabilities, and VMware continues to reach parity or exceed the feature sets of their competition.

Horizon EUC Access Point Configuration Script

Horizon 6.2 included a new feature when it was launched in early September – the EUC Access Gateway.  This product is a hardened Linux appliance that has all of the features of the Security Server without the drawbacks of having to deploy Windows Servers into your DMZ.  It will also eventually support Horizon Workspace/VMware Identity Manager.

This new Horizon component exposes the “cattle philosophy” of virtual machine management.  If it stops working properly, or a new version comes out, its to be disposed of and redeployed.  To facilitate this, the appliance is configured and managed using a REST API.

Unfortunately, working with this REST API isn’t exactly user friendly, especially if you’re only deploying one or two of these appliances.  This API is also the only way to manage the appliance, and it does not have a VAMI interface or SSH access.

I’ve put together a PowerShell script that simplifies and automates the configuration of the EUC Access Gateway Appliances.  You can download the script off of my Github site.

The script has the following functions:

  • Get the appliance’s current Horizon View configuration
  • Set the appliance’s Horizon View configuration
  • Download the log bundle for troubleshooting

There are also placeholder parameters for configuring vIDM (which will be supported in future releases) and uploading SSL certificates.

The syntax for this script’s main features look like:

Set-EUCGateway -appliancename 10.1.1.2 -adminpassword P@ssw0rd -GetViewConfig

Set-EUCGateway -appliancename 10.1.1.2 -adminpassword P@ssw0rd -SetViewConfig -ViewEnablePCoIP -ViewPCoIPExternalIP 10.1.1.3 $ViewDisableBlast

Set-EUCGateway -appliancename 10.1.1.2 -adminpassword P@ssw0rd -GetLogBundle -LogBundleFolder c:\temp

If you have any issues deploying a config, use the script to download a log bundle and open the admin.log file.  This file will tell you what configuration element was rejected.

I want to point out one troubleshooting note that my testers and I both experienced when developing this script.  The REST API does not work until an admin password is set on the appliance.  One thing we discovered is that there were times when the password would not be set despite one being provided during the deployment.  If this happens, the script will fail when you try to get a config, set a config, or download the log bundle.

When this happens, you either need to delete the appliance and redeploy it or log into the appliance through the vSphere console and manually set the admin password.

Finally, I’d like to thank Andrew Morgan and Jarian Gibson for helping test this script and providing feedback that greatly improved the final product.

What’s New in VMware Horizon 6.2–User Experience

One of the areas where Horizon 6.2 has a lot of improvements is in the User Experience category.  The new version adds new features as well as brings a few older features out of tech preview.

Client Drive Redirection for VDI and RDSH

Client Drive redirection for Windows was in Tech Preview in Horizon 6.1.1.  It officially comes out of Tech Preview in Horizon 6.2, and it is now supported on both Windows and Mac clients.  It is also available as a tech preview for Linux clients.

This feature, when installed on the virtual desktop, allows users to remotely access files and data that might have stored on their local PC.  It utilizes compression and encryption when transferring files from the endpoint into the virtual desktop or server. 

Windows 10 Support

Although Windows 10 was officially supported on vSphere 6 on Day 1, it wasn’t supported in Horizon.  Virtual desktops built on Windows 10 would work, but there limits to what you could do, and other components of the Horizon Suite were not designed to work with or support it.

Horizon 6.2 has full support for Windows 10.  The Horizon Agent and Client are supported.  This includes Smart Card authentication support.

Windows 10 is only supported when running ESXi 5.5 Update 3 or ESXi 6.0 Update 1.

File Type Associations for Published Apps

There are times when I may want to allow a user to launch an application or work with files without installing the required applications on their machines.  In these cases, the user would then have to log into Horizon, launch the application, and then navigate to the network location where the file was stored.

But what if I could register a file handler in Windows that would allow me to double click on that file and have it launch the remote application automatically?  Horizon 6.2 now adds this capability.

In order to improve the user experience when opening files remotely, a data compression algorithm is utilized when transferring the files up to the remote host.  This transfer is also protected with SHA 256 encryption for when clients are remotely accessing the remote application over the Internet.

Mac OSX and IOS Support

Horizon Client 3.5 will be supported on OSX 10.11 and IOS 9.

Biometric Authentication

The Horizon Client for IOS will support biometric authentication.  This feature will allow users to store their credentials in Keychain and utilize their fingerprints to sign into their virtual desktops or published applications.  Administrators can also define polices for who can use this feature from with the Horizon Administrator console.

This feature is only supported with Horizon 6.2 when using Horizon Client 3.5.  The mobile device must also be running IOS 8 or IOS 9.

What’s New in VMware Horizon 6.2–3D Graphics

3D graphics are becoming increasingly important in virtual desktop environments.  While a number of high-end applications and use cases, such as CAD and medical imaging, require 3D graphics, modern applications are increasingly turning to the GPU to offload some processing.  These days, most web browsers, Microsoft Office, and even Windows are utilizing the GPU to assist with rendering and other tasks.

VMware has been slowly adding 3D support to Horizon.  Initially, this was limited to dedicating GPUs to a virtual machine or sharing the GPU through hypervisor-level components.  Horizon 6.1 added  NVIDIA’s vGPU to provide better shared GPU access.

Horizon 6.2 includes a significant number of improvements to virtual 3D acceleration.  In fact, most of the improvements are in this category.

NVIDIA GRID 2.0

NVIDIA announced the next generation of GRID on Sunday afternoon.  For more information, see my write-up on it here.

vDGA for AMD GPUs

AMD/ATI graphics cards were supported on virtual desktops in vSphere 5.x and Horizon 5.x.  This did not carry over to Horizon 6.  AMD support has been reintroduced in Horizon 6.2 for vDGA.

3D Support for RDS Hosted Applications

RDS desktops and published applications will now support both vDGA and vGPU when utilizing supported NVIDIA graphics cards.  3D acceleration is supported on RDSH servers running Windows Server 2008 R2 and Windows Server 2012.

Linux Desktop vSGA and vGPU Support

When Linux desktops were introduced in Horizon 6.1.1, they only supported vDGA for 3D graphics.  This limited Linux to a few specific use cases.

Horizon 6.2 adds significant support for 3D acceleration.  Both vSGA and vGPU are now available when utilizing supported NVIDIA graphics cards.

Linux desktops with vGPU will be able to utilize OpenGL 2.1, 3.x, and 4.x, while desktops with vSGA will be limited to OpenGL 2.1.

4K Resolution Support

4K content is extremely high resolution content, and more 4K content will appear as the displays start to come down in price.  These displays, which have a resolution of 3840×2160, are useful in situations where high resolution imaging is needed.

Horizon 6.2 will support in-guest resolutions up to 3840×2160.  In order to achieve this, Horizon Agent 6.2 is needed in the guest, and the client must be connecting with Horizon Client 3.5.

The guest operating system must be running Windows.  A Windows 7 virtual desktop can support up to three 4K monitors when running on a VM with HW version 11 and with Aero disabled.  Windows 7 machines with Aero enabled, or Windows 8 desktops running on HW version 10 can support a single 4K monitor.

Please note that this is for in-guest display resolutions.  Clients that have a 4K display with High DPI scaling are not supported at this time.

What’s New in VMware Horizon 6.2 – RDSH and Application Publishing

Publishing applications from RDSH servers was one of the big additions to Horizon 6.0.  Horizon 6.2 greatly expands on this feature set, and it offers many new capabilities under the covers to improve the management of the environment.

Cloud Pod Support for Applications

Horizon’s Cloud Pod for multi-datacenter architectures has been expanded to include support for RDSH-published applications.  Users can now be entitled to an application once and access them across Horizon pods and/or datacenters. 

image

Enhanced RDSH Load Balancing

The load balancing and user placement algorithms have been enhanced in Horizon 6.2 to ensure that users do not get placed on an already overloaded server.  There are two main improvements that enable this:

1. The load balancing algorithm utilizes Perfmon counters to determine which hosts are optimal for starting new sessions.  The View agent runs a script to collect system performance data, and it reports back to the connection servers with a recommendation based on the system’s current performance.  A server placement order is calculated based on the data that the View Agents return.

2. Application anti-affinity rules will look at the number instances of an application that is running on an RDSH host.  If the number of a particular application is higher than a predefined value, user connections will be directed to another host.  Application anti-affinity rules process after the server placement order has been determined.

There are a couple of things to be aware of with the new load balancing algorithms.  First, they only apply to new sessions, so if a user already has a session on an RDSH server, they will be reconnected to that session and be able to launch any application, even if it violates an anti-affinity rule.

Application anti-affinity rules also do not apply to RDSH desktop sessions.

Linked-Clone Support and Horizon Composer for RDSH

If you had wanted to build an RDSH Farm for Horizon 6.0, you would have had to build, deploy, and manage each server manually.  There was no built-in way for managing server images or server updates.  This could also be an inefficient use of storage.

Horizon 6.2 changes this.  Composer now supports linked-clone RDSH servers.  This brings the benefits of linked-clone desktops, such as automated pool builds, single image management, and system and application consistency, to server-based computing.

What’s New in VMware Horizon 6.2–Core Infrastructure

In order to set up and run VMware Horizon, you need to have a vSphere infrastructure and Windows VMs to run the server components.  Horizon 6.2

Horizon Access Point

One of the challenges of deploying Horizon is that, in order to provide external access, you need to deploy Windows machines into your network’s DMZ.  These servers, called Security Servers, run a subset of the Connection Broker that proxies or tunnels PCOIP, Blast, and RDP connections into your environment.

Horizon Security Servers have their limitations, though.  To start with, they are usually not joined to an Active Directory domain, so they cannot be configured or managed with the Group Policies that manage the rest of your infrastructure.  Because these servers live in the DMZ, they also need to be patched frequently and secured.

Security Servers are also paired directly with a Connection Server.  If the Connection Server is not available, users who connect with that particular security server would not be able to authenticate or connect to a desktop.  This also limits the number of servers you can deploy to a maximum of seven. 

Horizon 6.2 will now include a new method of providing remote access called the Access Point.  The Access Point is a locked-down virtual appliance built on SUSE Linux Enterprise Edition 11 that has feature parity with the Security Server.  It allows you to remove Windows VMs from your DMZ, and it does not need to be paired with a Connection Server, so you can scale out your external access without having to add additional connection servers.

The Access Point will not be dedicated to Horizon View.  It is designed to work with all components of the Horizon Suite – reducing the number of external access components that you need to manage.

image

One-Way Trust Support

If you work in a multi-domain or federated environment, Horizon View required a two-way trust between domains or forests in order to authenticate and entitle users.

There are a number of environments where two-way trusts aren’t feasible.  Think about companies that routinely undergo mergers, acquisitions, or divestitures.  They have use cases for virtual desktop environments, but a two-way trust between Active Directory environments would pose security and integration challenges.

Horizon 6.2 takes a step towards resolving this by adding support for 1-way Active Directory trusts.  Users and groups from external (trusted) domains can now be granted access to Horizon desktops without having to create a full two-way trust.

image

In order to fully support one-way forest trusts, Horizon will need to utilize a service account with permissions to authenticate against the trusted domain.  This account is stored in the Horizon LDAP database, and all of its credentials are encrypted.

Secondary credentials are managed by using the vdmadmin command line tool that is installed on Connection Servers.

vSphere 6 Update 1 Support

Horizon 6.2 will support vSphere 6 Update 1 on Day 1.

FIPS and Common Criteria Certification

The US Federal Government has a number of criteria that IT products must meet.  These include things like IPv6 compatibility, FIPS cryptographic support, and Common Criteria certification.

Horizon 6.1 introduced support for IPv6.  Horizon 6.2 expands upon this with support for FIPS on all Horizon Windows components.  FIPS will also be supported in Horizon Client 3.5 for Windows.

FIPS mode is optional, and it can be enabled if it is required.

VMware will also be submitting Horizon 6.2 for Common Criteria certification, and this testing is currently in process.  It should be completed sometime in 2016.

Enhanced License Console

The license console in previous versions of Horizon was not very detailed.  It would give you the current number of active users with a breakdown by virtual machine type.

Horizon 6.2 overhauls the licensing console on the Admin page.  The new licensing console shows part of the key that is in use along with the number of concurrent connections and unique named users that have logged in.

Introducing Horizon 6.2

VMware has made a significant investment in end-user computing.  A new release of Horizon comes about every six months, and each release contains several major new features.

Today, VMware has announced the latest iteration of Horizon Suite – Horizon 6.2.  This release greatly builds upon the features that have been released in the last few versions of Horizon.

These features include:

  • Significant expansion of RDSH capabilities
  • Enhancements to user experience
  • Expanded Graphics support
  • Windows 10 support
  • And more…

One thing we won’t be seeing in this version is the release of Instant Clones.  This was announced at last year’s VMworld as Project Fargo, and it utilizes the instant cloning features to create on-demand virtual desktops.

The Next Generation of Virtual Graphics–NVIDIA GRID 2.0

When vGPU was released for Horizon View 6.1 back in March 2015, it was an exciting addition to the product line.  It addressed many of problems that plagued 3D Graphics Acceleration and 3D workloads in virtual desktop environments running on the VMware platform.

vGPU, running on NVIDIA GRID cards, bridged the gap between vDGA, which is dedicating a GPU to a specific virtual machine, and vSGA, which is sharing the graphics card between multiple virtual machines through the use of a driver installed in the hypervisor.  The physical cores of the GRID card’s GPU could be shared between desktops, but there was no hypervisor-based driver between the virtual desktop and the GPU.  The hypervisor-based component merely acted as a GPU scheduler to ensure that each virtual desktop received the resources that it was guaranteed.

While vGPU improved performance and application compatibility for virtual desktops and applications, there were certain limitations.  Chief amongst these limitations was support for blade servers and virtual machines running Linux.  There were also hard capacity limits – GRID cards could only support so many virtual desktops had vGPU enabled.

Introducing GRID 2.0

Today, NVIDIA is announcing the next generation of virtual Graphics Acceleration – GRID 2.0.

GRID 2.0 offers a number of benefits over the previous generation of GRID cards and vGPU software.  The benefits include:

  • Higher Densities – A GRID card with 2 high-end GPUs can now support up to 32 users.
  • Blade Server Support – GRID 2.0 will support blade servers, bringing virtual desktop graphics acceleration to high-density compute environments.
  • Linux Desktop Support – GRID 2.0 will support vGPU on Linux desktops.  This will bring vGPU to a number of use cases such as oil and gas.

GRID 2.0 will also offer better performance over previous generations of GRID and vGPU.

Unfortunately, these new features and improvements aren’t supported on today’s GRID K1 and K2 cards, so that means…

New Maxwell-based GRID Cards

NVIDIA is announcing two new graphics cards alongside GRID 2.0.  These cards, which are built on the Maxwell architecture, are the M60 – a double-height PCI-Express card with two high-end Maxwell cores, and the M6 – a GPU with a single high-end Maxwell core that is designed to fit in blades and other rack-dense infrastructure.  The M6 is designed to have approximately half of the performance of the M60.  Both cards double the amount of memory available to the GPU.  The M6 and M60 each have 8GB of RAM per GPU compared to the 4GB per GPU on the GRID K1 and K2.

Both the M6 and the M60 will be branded under NVIDIA’s TESLA line of data center graphics products, and the GRID 2.0 software will bring the graphics virtualization capabilities on top of these new Maxwell-based Tesla cards..  The M60 is slated to be the direct replacement for both the GRID K1 and GRID K2 cards.  The K1 and K2 cards will not be discontinued, though – they will still be sold and supported for the foreseeable future.

GPUs Should Be Optional for VDI

Note: I disabled comments on my blog in 2014 because of spammers. Please comment on this discussion on Twitter using the #VDIGPU hashtag.

Brian Madden recently published a blog arguing that GPU should not be considered optional for VDI.  This post stemmed from a conversation that he had with Dane Young about a BriForum 2015 London session on his podcast

Dane’s statement that kicked off this discussion was:
”I’m trying to convince people that GPUs should not be optional for VDI.”

The arguments that were laid out in Brian’s blog post were:

1. You don’t think of buying a desktop without a GPU
2. They’re not as expensive as people think

I think these are poor arguments for adopting a technology.  GPUs are not required for general purpose VDI, and they should only be used when the use case calls for it.  There are a couple of reasons why:

1. It doesn’t solve user experience issues: User experience is a big issue in VDI environments, and many of the complaints from users have to do with their experience.  From what I have seen, a good majority of those issues have resulted from a) IT doing a poor job of setting expectations, b) storage issues, and/or c) network issues.

Installing GPUs in virtual environments will not resolve any of those issues, and the best practices are to turn off or disable graphics intensive options like Aero to reduce the bandwidth used on wide-area network links.

Some modern applications, like Microsoft Office and Internet Explorer, will offload some processing to the GPU.  The software GPU in vSphere can easily handle these requirements with some additional CPU overhead.  CPU overhead, however, is rarely the bottleneck in VDI environments, so you’re not taking a huge performance hit by not having a dedicated hardware GPU.

2. It has serious impacts on consolidation ratios and user densities: There are three ways to do hardware graphics acceleration for virtual machines running on vSphere with discrete GPUs.

(Note: These methods only apply to VMware vSphere. Hyper-V and XenServer have their own methods of sharing GPUs that may be similar to this.)

  • Pass-Thru (vDGA): The physical GPU is passed directly through to the virtual machines on a 1 GPU:1 Virtual Desktop basis.  Density is limited to the number of GPUs installed on the host. The VM cannot be moved to another host unless the GPU is removed. The only video cards currently supported for this method are high-end NVIDIA Quadro and GRID cards.
  • Shared Virtual Graphics (vSGA): VMs share access to GPU resources through a driver that is installed at the host level, and the GPU is abstracted away from the VM. The software GPU driver is used, and the hypervisor-level driver acts as an interface to the physical GPU.  Density depends on configuration…and math is involved (note: PDF link) due to the allocated video memory being split between the host’s and GPU’s RAM. vSGA is the only 3D graphics type that can be vMotioned to another host while the VM is running, even if that host does not have a physical GPU installed. This method supports NVIDIA GRID cards along with select QUADRO, AMD FirePro, and Intel HD graphics cards.
  • vGPU: VMs share access to an NVIDIA GRID card.  A manager application is installed that controls the profiles and schedules access to GPU resources.  Profiles are assigned to virtual desktops that control resource allocation and number of virtual desktops that can utilize the card. A Shared PCI device is added to VMs that need to access the GPU, and VMs may not be live-migrated to a new host while running. VMs may not start up if there are no GPU resources available to use.

Figure 1: NVIDIA GRID Profiles and User Densities
clip_image001[10]

There is a hard limit to the number of users that you can place on a host when you give every desktop access to a GPU, so it would require additional hosts to meet the needs of the VDI environment.  That also means that hardware could be sitting idle and not used to its optimal capacity because the GPU becomes the bottleneck.

The alternative is to try and load up servers with a large number of GPUs, but there are limits to the number of GPUs that a server can hold.  This is usually determined by the number of available PCIe x16 slots and available power, and the standard 2U rackmount server can usually only handle two cards.   This means I would still need to take on additional expenses to give all users a virtual desktop with some GPU support.

Either way, you are taking on unnecessary additional costs.

There are few use cases that currently benefit from 3D acceleration.  Those cases, such as CAD or medical imaging, often have other requirements that make high user consolidation ratios unlikely and are replacing expensive, high-end workstations.

Do I Need GPUs?

So do I need a GPU?  The answer to that question, like any other design question, is “It Depends.”

It greatly depends on your use case, and the decision to deploy GPUs will be determined by the applications in your use case.  Some of the applications where a GPU will be required are:

  • CAD and BIM
  • Medical Imaging
  • 3D Modeling
  • Computer Animation
  • Graphic Design

You’ll notice that these are all higher-end applications where 3D graphics are a core requirement.

But what about Office, Internet Explorer, and other basic apps?  Yes, more applications are offloading some things to the GPU, but these are often minor things to improve UI performance.  They can also be disabled, and the user usually won’t notice any performance difference.

Even if they aren’t disabled, the software GPU can handle these elements.  There would be some additional CPU overhead, but as I said above, VDI environments usually constrained by memory and have enough available CPU capacity to accommodate this.

But My Desktop Has a GPU…

So let’s wrap up by addressing the point that all business computers have GPUs and how that should be a justification for putting GPUs in the servers that host VDI environments.

It is true that all desktops and laptops come with some form of a GPU.  But there is a very good reason for this. Business desktops and laptops are designed to be general purpose computers that can handle a wide-range of use cases and needs.  The GPUs in these computers are usually integrated Intel graphics cards, and they lack the capabilities and horsepower of the professional grade NVIDIA and AMD products used in VDI environments. 

Virtual desktops are not general purpose computers.  They should be tailored to their use case and the applications that will be running in them.  Most users only need a few core applications, and if they do not require that GPU, it should not be there.

It’s also worth noting that adding NVIDIA GRID cards to servers is a non-trivial task.  Servers require special factory configurations to support GPUs that need to be certified by the graphics manufacturer.  There are two reasons for this – GPUs often draw more than the 75W that a PCIe x16 slot can provide and are passively cooled, requiring additional fans.  Aside from one vendor on Amazon, these cards can only be acquired from OEM vendors as part of the server build.

The argument that GPUs should be required for VDI will make much more sense when hypervisors have support for mid-range GPUs from multiple vendors. Until that happens, adding GPUs to your virtual desktops is a decision that needs to be made carefully, and it needs to fit your intended use cases.  While there are many use cases where they are required or would add significant value, there are also many use cases where they would add unneeded constraints and costs to the environment.