One of the most important steps when building a virtual desktop infrastructure is to select the proper scenario for migration to virtual desktops. There are plenty of great examples when VDI is a good choice -- for call center operators, remote developers or task workers -- but it has lagged in other areas due to slow screen refresh.
Due to the graphics-heavy nature of computer-aided design, 3-D modeling and animation rendering, those users have had to remain on physical workstations with dedicated graphics processing hardware necessary to process graphics-intensive tasks. With the latest releases of VMware View and vSphere, options for virtualizing these areas are now available.
How older versions of View handled 3D
Previous releases of View and vSphere included two options to provide 3-D graphics to virtual desktops. The least powerful option is a pure software implementation of a 3-D graphics card. Using this option, no physical graphics processing unit (GPU) is necessary in the ESXi host server. All the graphics processing is done in the CPU, and all the necessary drivers for the VM are included in the Super Video Graphics Array (SVGA) package within
The other option is the virtual Shared Graphics Acceleration (vSGA), which requires a physical GPU and is virtualized by the hypervisor. This allows multiple VMs to share a single GPU, similar to the way the physical CPU is shared by multiple VMs. This has eased the way for many additional use cases but is still limited by the hypervisor.
The VMware SVGA driver executes vSGA, requiring no additional work within the VM. However, a vSphere Installation Bundle (VIB) package needs to be installed on the ESXi server for the hypervisor to address the graphics card. The card manufacturers create and maintain the driver package, which is specific to the graphics adapter installed.
Since both the software 3-D and the vSGA implementations are based on the VMware SVGA driver and are dependent on the hypervisor presenting a graphics card to the VM, vMotion is supported in both configurations. If the VM is configured in both the vSphere Web Client and View Administrator consoles to use the automatic rendering, using vMotion to move the VM from a host with a physical graphics card to a host not containing a physical graphics card is supported. This change -- which will happen automatically -- forces the VM from a vSGA configuration into a software 3-D configuration. A decrease in performance may be experienced, however.
New View gains more 3-D graphics processing power
In Horizon View 5.3, VMware introduced full support for virtual Direct Graphics Acceleration (vDGA). With this feature, a physical graphics card is tied to a VM, bypassing the hypervisor to provide near-native performance. Having this one-to-one mapping allows for some of the most demanding 3-D graphics tasks to move into a virtual desktop environment.
Implementing vDGA requires installing the graphics card drivers in the VM. The VM must then be configured to allow direct access to the graphics card using VMware DirectPath within the vSphere Web Client. Now the graphics card can be configured and used as if it were in a physical machine. Since the VM addresses the graphics card, no VIB package is necessary.
With great power comes a few shortcomings
Mapping a GPU to a single VM does have downsides. Like any VMware DirectPath I/O device, vMotion is no longer possible since the VM relies on a specific piece of hardware. If more than one VM needs vDGA, then multiple GPUs need to be installed.
There is also a very limited compatibility list at this time for GPUs in an ESXi host. NVIDIA has been an early partner with VMware and currently has the most extensive support. If intense 3-D workloads will be in use, the client device and connectivity will need to be on the high end to keep up with the rate of change on the display.
This was first published in January 2014