I want to take a moment and talk for a second about an oft mentioned but little understood new feature of vSphere 6. Specifically NVIDIA’s vGPU technology.
First, we need to know that vGPU is a feature of vSphere Enterprise Plus edition; which means it’s also included in vSphere for Desktops. But if this sounds like something you need and you’re running Standard or Enterprise, now might be a good time think about upgrading, and taking advantage of the trade up promotions.
Many folks think “I don’t need 3D for my environment. We only run office.” If that’s you, then please take a good close look at what your physical desktop’s GPU is doing while you run office 2013; especially PowerPoint. Nearly every device sold since ~1992 has had some form of hardware based graphics acceleration. No so your VM’s. Software expects this. Your users will demand it.
With that, let’s talk about what we’ve had for a while as relates to 3D with vSphere. Understand you can take advantage of these features regardless of what form of Desktop or Application virtualization you choose to deploy because it’s a feature of the virtual machine.
No 3D Support – I mention this because it is an option. You can configure a VM where 3D support is disabled. Here an application that needs 3D either has to provide it’s own software rendering, or it will simply error out. If you know your App doesn’t use any 3D rendering at all this is an option to ensure that no CPU time or memory is taken up trying to provide the support. No vSphere drivers are required.
Software 3D – Ok, here we recognize that DirectX and OpenGL are part of the stack and that some applications are going to use them. VMware builds support into their VGA driver (part of VMware Tools) that can render a subset of the API’s (DX9, OpenGL 1.2) in software, using the VM’s CPU. This works for a set of apps that need a little 3D to run, and we aren’t concerned about the system CPU doing the work. No hardware ties here as long as you can live with the limited API support and performance. No vSphere drivers are required. No particular limits on how many VM’s can do this beyond running out of CPU.
vSGA – or Virtual Shared Graphics – In this mode the software implementation above gets a boost by putting a supported hardware graphics accelerator in to the vSphere host. The API support is the same because it’s still the VMware VGA driver in the VM, but it hands off the rendering to an Xorg instance in the service console which in turn does the rendering on the physical card. This mode does require a supported ESXi .vib driver, provided by the card manufacturer. That means you can’t just use any card, but have to buy one specifically for your server and which has a driver. NVIDIA and AMD provide these for their server centric GPU cards. Upper bound of VM’s is determined by the amount of video memory you assign to the VM’s and the amount of memory on your card.
vDGA – or Virtual Dedicated Graphics – In this mode we do a PCI pass-through for a GPU card to a given virtual machine. This means that the driver for the GPU resides inside the virtual machine and VMware’s VGA driver is not used. This is a double (or tripple) edge sword. Having the native driver in the VM ensures that the VM has the full power and compatibility of the card, including latest API’s supported by the driver (DX11, OpenGL 4, etc.). But having the card assigned to single VM means no other VM’s can use it. It also means that the VM can’t move off it’s host (no vMotion, no HA, no DRS). This binding between the PCI device and the VM also prevents you from using View Composer or XenDesktop’s MCS, though Citrix’s Provisioning Services (PVS) can be made to work. So this gives great performance and unmatched compatibility but at a pretty significant cost. It also means that we do not want a driver installed for ESXi since we’re only going to pass-through the device. That means you can use pretty much any GPU you want. You’re limit on how many VM’s per host is tied to how many cards you can squeeze into the box.
All of the above are available in vSphere 5.5, with most of it actually working under vSphere 5.1. I’ve said if you care about your user experience you wanted to have vSGA as a minimum requirement and consider vDGA for anyone who’s running apps that clearly “need” 3D support. Though vDGA’s downside has had a way of pushing it out of of high volume deployments.
Ok so what’s new? The answer is NVIDIA vGPU. The first thing to be aware of is that this is an NVIDIA technology, not VMware. That means you won’t see vGPU supporting AMD (or anyone else’s) cards any time soon. Those folks will need to come up with their own version. NVIDIA also only supports this with their GRID cards (not GeForce or Quadro). So you’ve got to have the right card, in the right server. Sorry, that’s how it is. It’s only fair to mention that vGPU first came out for XenServer about two years ago, and came out for vSphere with vSphere 6.0. So while it’s new to vSphere, it’s not exactly new to the market.
So what makes this different? vGPU is a combination of an ESXi driver .vib and some additional services that make up the GRID manager. This allows dynamic partitioning of GPU memory and works in concert with a GRID enabled driver in the virtual machine. The end result is that the VM runs a native NVIDIA driver with full API support (DX11, OpenGL 4) and has direct access (no Xorg) to the GPU hardware, but is only allowed to use a defined portion of the GPU’s memory. Shared access to the GPU’s compute resources is governed by the GRID manager. Net-Net is that you can get performance nearly identical to vDGA without the PCI pass-through and it’s accompanying downsides. vMotion remains a ‘no’ but VMware HA and DRS do work. Composer does work, and MCS works. And, if you set your VM to use only 1/16th of the GPU’s memory then you have the potential to share the GPU amongst 16 virtual machines. Set it to 1/2 or 1/4 and get more performance (more video RAM) but at a lower VM density.
So why does this matter? It means we get performance and comparability for graphics applications (and PowerPoint!) and an awesome (as in better than physical) user experience while gaining back much of what drove us to the virtual environment in the first place. No more choosing between a great experience and management methods, HA, and DR. Now we can have it all.
If you’re using graphics, you want vGPU! And if you’re running Windows apps, you’re probably using graphics!