The second half of 2013 saw huge buzz around a compelling new feature in desktop virtualization !; virtualized graphics processing.
I posted before about how you need to prepare for the arrival of sharing hardware GPU, and there was some excellent blogs covering updates to Pro Graphics with HDX 3D XenDesktop 7.1. However, you know that you are on something big when industry analysts as Gunnar Berger display different graphics models comparisons.
The good news is that December 16 e 2013 Citrix and NVIDIA will release full support for XenDesktop 7.1 HDX 3D Pro with XenServer 6.2 SP1 to provide sharing GPU real hardware with NVIDIA GRID K1 and K2 cards.
What I want to do is both to consolidate some of the information out there, and explain when a given technology might be a better choice. After all, we are now in a time when the choice of hypervisor is driven not by personal preference, but the workload type, it is optimized to provide. In this case, the workload is one that has graphics requirements of high performance, which must be securely delivered from the data center to a virtualized manner. Model
access models dedicated
The easiest graphics VDI is the direct access method. In a direct access method, a given GPU is assigned to a specific virtual machine and VM that has full access to the capabilities of the card. If you are a fan of vSphere, then you will recognize this model as vDGA and if you are a fan XenServer This is called GPU pass-through.
Regardless of the hypervisor, you interact with the underlying video card via the drivers of the graphics chipset supplier, and any shared access occurs within the virtual machine and its application stack. Due to the direct assignment of GPUs for specific virtual machines, shared access to the GPU through virtual machines is not possible, but each virtual machine can be a multi-user Windows Server RDS machine.
Now, the beauty of this model is that you get indeed access to the functionality of the video card, but in the case of a single user's Windows desktop VM, it comes to an additional cost; the density of users. Indeed the maximum number of virtual machines you can run is limited by the number of GPU you can put in a server. Obviously, you can overload the server with non-graphical virtual machines, but since the objective is to optimize performance for heavy graphics applications, the server load can create CPU starvation in graphics applications.
shared access models
regarding shared access to a GPU by multiple virtual machines only user, there are really three distinct models available; emulation, API interception, and sharing of GPU hardware. While there is nothing inherently wrong with any of these solutions, there is certainly a compromise in terms of performance and scalability. In each of these approaches, it is a cooperative between the hypervisor drivers and guest conductors to provide a specific use case.
VMware vSGA
Graphics Access Shared Virtual (vSGA) is a VMware solution designed to provide shared access to a GPU for the purposes of delivering HTML5, WebGL, Web 2.0 applications and other rich multimedia type applications.
in each guest there is a VMware driver that in turn interfaces with a specific GPU driver in vSphere to provide shared access to the frame buffer in the GPU. The VMware driver is responsible for providing access to the GPU hardware emulated underlying GPU in the stack of the operating system. This means that applications specifically designed to work with NVIDIA driver must be recertified against the VMware driver and the advanced GPU present in the operating system battery capacity may not be available for applications.
vSGA is limited to DirectX 9.0c (released in 04) and OpenGL 2.1 (released in 06), and graphics acceleration VMware Deployment Guide states that if new versions are required; "Applications requiring newer versions may not perform or function properly" and that some applications are certified for "reviewers and mild cases of use." In such scenarios, VMware recommends vDGA.
Microsoft RemoteFX vGPU
The battery of the RemoteFX technology includes the ability to provide a virtualized GPU access when Hyper-V is used as the hypervisor. RemoteFX vGPU is primarily designed to support the Windows Aero experience in a VDI scenario, and Windows Server 2012 can operate without a physical GPU.
To take advantage of RemoteFX vGPU, physical GPUs must have DirectX 11.1 drivers available to it, and vGPU present DirectX 9 or DirectX 11 on your VM. Since DirectX is the primary API for graphics operation, and since the driver in the primary partition Hyper-V provides a super-set of functions, RemoteFX can proxy graphics calls between the client and the host to deliver an optimized graphics experience DirectX enabled applications do not require full access to a GPU. XenDesktop VDI supports RemoteFX vGPU when used with RDP and Citrix Receiver for Windows.
XenServer vGPU
In XenServer vGPU, the shared driver model used by XenServer allows NVIDIA driver to load into the XenServer control domain, and an NVIDIA driver to be loaded in the virtual machine invited. This has the major advantage of ensuring access to the GRID card is properly managed using the NVIDIA drivers, and user point of view that applications that are certified for NVIDIA drivers continue to operate as anticipated; without modification. One of the immediate benefits of this approach is that NVIDIA drivers natively support the latest versions of DirectX and OpenGL.
If you want to see the current list of validated applications for deployment on vGPU XenDesktop 7.1 HDX 3D Pro, please refer to the certification list of NVIDIA remote workstations.
ultimately, the choice is yours to make. Each of these solutions have their strengths, but when it comes to providing the best possible graphics experience your choice comes down to either a direct access model, or XenServer vGPU with NVIDIA GRID feeding XenDesktop HDX 3D Pro.
Whether you are supporting architects, engineers, designers, graphic designers, or workers who need access to 3D data models; we now offer you a solution that offers all the benefits of secure remote access without compromising graphical fidelity or user density.
0 Komentar