May 6, 2015 at 19:16Why not RemoteFX, and more about NVIDIA GRID VGPU technology
The increase in the number of jobs in the enterprise and the growth of the IT infrastructure as a whole sooner or later makes us think about a number of issues related to the more competent construction of the IT infrastructure itself, aimed at solving the following tasks facing the IT department:
The most popular solution to the first and second sounded tasks is the introduction of terminal servers in the enterprise and the replacement of expensive workstations with thin clients. Indeed, in conditions of constant need for the purchase of hardware and software, a terminal server and thin clients can reduce the costs associated with an increase in the number of jobs, as well as allow IT department employees to use more convenient and transparent mechanisms for administering and maintaining the aforementioned jobs. Virtualization of workstations and servers does an excellent job of implementing the solution to the third problem. The powerful toolkit of various modern hypervisors allows employees of the IT department to make backups discreetly for users and,
However, sometimes the capabilities of a remote terminal server or operating system session deployed as a guest are not enough. I’m talking about cases when a user working for a thin client using the capabilities of the remote desktop needs to work with a specific set of programs, for example, various CAD programs and other software related to the use of 3D graphics. It is not necessary to return to the use of full-fledged, independent jobs. Manufacturers of video cards and servers, together with developers of various virtual platforms, have long thought about using the capabilities of a physical video card in guest operating systems. However, not all developers of hypervisors succeeded (or maybe they did not want to) develop a general concept of using the capabilities of a video card with virtual machines, which was proposed by leading manufacturers of computing graphics modules. There are many holivars on this topic, I will try to do without participating in them and assess the state of things based only on dry facts.
For quite some time now I have been familiar with the Microsoft hypervisor called Hyper-V. It should be noted that this hypervisor with each next generation of the server platform Windows Server is becoming more functional and intuitive to administer. PowerShell adds new cmdlets that make it easy to manage the hypervisor. There is a great opportunity to implement with the help of scripts even such necessary tasks as backing up virtual machines and creating scheduled snapshots in the scheduler without using third-party and rather expensive programs. It’s easy to administer Hyper-V, the performance of the hypervisor is not satisfactory, the list of operating systems that either have installed services for integrating with the hypervisor or have the ability to install such services is constantly growing, or supporting Hyper-V thanks to kernel modules. More recently, the release of FreeBSD 10.0, the first of the BSD systems, which was easily and effortlessly installed as a guest on the Microsoft hypervisor, and which got rid of children's sores, such as the limited size of the virtual hard disk and the ability to use only an outdated network adapter (legacy or emulated), was just recently released. ), whose speed cannot exceed 100Mbit / s, while the physical network adapter is gigabit. In general, as it may seem, the tendency to improve has a very positive trend. That is why we initially started looking for the answer to the question of whether there is the possibility of using a physical video card in the guest operating system Hyper-V. The answer, it seemed to us then, I didn’t take long to wait and after 5 minutes, judging by the articles on the Internet, we were sure that such an opportunity existed and, moreover, it was qualitatively implemented by Hyper-V developers. As it turned out, we were cruelly mistaken, but first things first.
Microsoft proposed RemoteFX technology as a solution, which was originally developed by Calista Technologies, which was later acquired by Microsoft. The technology itself has very significant hardware requirements for both the virtualization server and the video card, which will be further used by the guest operating system through this technology. The requirements are that the server itself must have a CPU with SLAT support (EPT on Intel, NPT / RVI on AMD), but with the GPU it is still more fun. Here are the actual requirements and recommendations voiced by Microsoft itself:
There are many guides to deploy RemoteFX on Windows Server in the vast web. However, almost none of these articles are talking about the quality application, but basically the article has such a complete meaning: “Raised it, picked it up, it seems to work, it seems that it even moves faster, it seems that even the load on the central processor has been reduced. What was he doing for? The devil knows him. ”
So, I want to tell you about our experience in finding a solution to the problem of expanding the capabilities of virtual machines in 3D graphics processing. We had a rather clearly defined task. We had to make sure that users of remote desktops of a terminal server deployed on the Windows Server 2012 R2 platform were able to at least qualitatively view various 3D drawings and assemblies in specialized viewers, and at most they themselves could no, no, and run various CAD programs.
The initial idea was to deploy RemoteFX on Windows Server 2012R2. No sooner said than done. There was a server platform DELL PowerEdge R720 equipped with two Intel Xeon processors CPU E5-2670 v2 @ 2.50GHz supporting SLAT, as well as an NVIDIA GRID K2 computing graphics module. A Windows Server 2012R2 standard operating system with a graphical shell was installed on the server, the Hyper-V service was deployed and RemoteFX was configured. In fact, then we thought that this was the final solution and RemoteFX technology would completely suit us. However, in the future we learned that Microsoft imposes on technology and significant software requirements that as a guest operating system that can use the 3D graphic adapter RemoteFX, only Windows 7 and 8 operating systems can perform, and only in the Ultimate and Enterprise editions. Not entirely true of course, given that the hypervisor itself, according to its developers, supports a lot of other operating systems.
It became clear that our goal of using a graphics adapter in a virtual terminal server, which is deployed on Windows Server 2012R2, will remain unrealizable. Okay, we are working with what we have. So what do we have? Very little. Just the possibility of installing Windows 7-8 Ultimate-Enterprise as a guest operating system with the ability to connect only one user to them. And even the beautiful RDP Wrapper library is not able to solve this problem. In addition, as we learned from the performance results, RemoteFX’s three-dimensional graphics adapter is practically not able to work with APIs such as OpenGL, which most CAD programs use, and instead fully support Microsoft’s only proprietary development for Windows - Direct3D.
What is this proprietary development to support the deployment of a terminal server based on virtual machines proposed in the latest generation of Windows Server? It is difficult to answer this question. However, only one thing is clear, RemoteFX technology is not applicable for solving our task, especially in view of the excessively high hardware and software requirements for the platform, server and guest operating systems. Of course, we are ready to satisfy all these requirements, but to end up with a turnkey solution with extremely dubious functionality is a waste.
That is why the search did not stop and, to our shame, the first time we paid attention to what NVIDIA herself writes about the graphic computing module he developed and its application. Read more hereIn short, NVIDIA created NVIDIA GRID vGPU technology, thanks to which the graphic commands of each virtual machine are transmitted directly to the GPU, without broadcast by the hypervisor. Thanks to the driver, one physical graphics module has several virtual GPU profiles with a different number of cores and discrete graphics memory. Here is the table of available virtual profiles for NVIDIA GRID graphics cards:
Everything is extremely simple and beautiful. The driver has the ability to isolate virtual profiles from the hardware platform of the board, which differ from each other in the number of graphic cores and memory, which can become an analogue of a physical video card in a virtual machine. While RemoteFX technology is just a software layer between a virtual machine and a real graphics card, which selectively transfers certain graphics to processing. Why then does Microsoft recommend using a graphics card whose functionality is not fully supported by the capabilities of their hypervisor? Why recommend this board for use if the hypervisor written by them does not follow the path of development of the concept proposed by the manufacturers of the graphics card? Unclear. However, it should be noted that in the description of the NVIDIA GRID VGPU technology on the NVIDIA website,
It was decided to try as a hypervisor XenServer 6.5 from Citrix, whose functionality in the Enterprise edition just supports the distribution of virtual graphic profiles between virtual machines. Although this has nothing to do with the article, I note that installing and configuring the server is simple and intuitive to the point of disgrace. The server was installed and activated with a trial license for 90 days, which can be obtained, taking into account the number of host sockets, in 5 minutes by registering on the developers website. Once activated, the profile sharing feature is available in XenCenter. Unfortunately, drivers exclusively for Windows operating systems are currently available for download, however, it’s good that the graphic profile can be installed not only on Windows 7-8 Ultimate-Enterprise,
To assess the quality of virtual graphic profiles, the guest operating system was Windows 8.1_x64_Enterprise, the first three profiles (K280Q, K260Q, K240Q) were added to the virtual machine settings, which are considered the most productive in descending order, and with each graphic profile 4 benchmarks were launched, testing 3D graphics performance using the OpenGL and Direct3D APIs. So that the comparison does not seem excessively abstract, a decision was made to compare the results of benchmarks running on a VM with the results of the same benchmarks running on a physical machine that has similar characteristics. Briefly about the technical characteristics of the virtual and physical machines can be found in the table below.
In the tables with benchmark results, I will indicate only the name of the graphics adapter.
So, the first benchmark will be SPECviewperf 12.0.2, which is revered by many experts as a benchmark for testing graphics of various CAD programs. Who cares, more details here . The results are in the table below. The window resolution is 1900x1060 everywhere (by default in the benchmark).
I spread all the results as is. I was a little embarrassed that the K260Q profile should in principle be “weaker” than the K280Q, but it showed more outstanding results. I double-checked it by running the test again on both profiles and came to the conclusion that the readings are stable (not random) and although they differ from the original, but within a reasonable range of 0.2-0.4.
The next benchmark, or rather a set of different benchmarks for testing OpenGL graphics, was GpuTest from geeks3d.com, more details can be found here . The results are in the table below in the format (points / FPS). All tests performed in full screen 1920x1080.
The next benchmark was the RedSDK turbine benchmark from REDWAY3D. More details here . The results are in the table below. All tests performed in full screen 1920x1080.
The latest benchmark was the free version of Heaven Benchmark 4.0 from Unigine developers. More details here . The choice fell on him, including because he can test Direct3D graphics. All tests were performed in a window with a resolution of 1280x720 due to the fact that the benchmark did not want to run in full screen mode on virtual machines for reasons unknown to me, giving an error. The results are in the tables below.
I will not draw any conclusions from the tests I have made; I’d better leave it to the public. To be honest, the test results are not completely clear to me and if the reader has something to comment on qualitatively, I will only be glad.
Summing up, I’ll say that all CAD programs and other software used in our company are successfully installed and run on virtual machines. It remains to give a specialist using these programs to work with remote desktop and let him make a final verdict on the possibility of using this solution. I also want to emphasize that I wrote this article not at all from idleness, but precisely because when I was looking for a solution to the task set by the IT department, I did not see such articles that fully disclose the differences between different technologies for forwarding the capabilities of the graphics card into the virtual machine, I did not see the articles, which describe the quality application of these technologies.
I hope the experience of our IT department is useful to someone. Thank you for attention.
- reduction in the cost of creating full-fledged jobs;
- creation of a more convenient mechanism for administering jobs by IT department staff and, as a result, reducing the time to perform certain operations related to technical support of users;
- Implementing the ability to backup and quickly restore data (or entire jobs).
The most popular solution to the first and second sounded tasks is the introduction of terminal servers in the enterprise and the replacement of expensive workstations with thin clients. Indeed, in conditions of constant need for the purchase of hardware and software, a terminal server and thin clients can reduce the costs associated with an increase in the number of jobs, as well as allow IT department employees to use more convenient and transparent mechanisms for administering and maintaining the aforementioned jobs. Virtualization of workstations and servers does an excellent job of implementing the solution to the third problem. The powerful toolkit of various modern hypervisors allows employees of the IT department to make backups discreetly for users and,
However, sometimes the capabilities of a remote terminal server or operating system session deployed as a guest are not enough. I’m talking about cases when a user working for a thin client using the capabilities of the remote desktop needs to work with a specific set of programs, for example, various CAD programs and other software related to the use of 3D graphics. It is not necessary to return to the use of full-fledged, independent jobs. Manufacturers of video cards and servers, together with developers of various virtual platforms, have long thought about using the capabilities of a physical video card in guest operating systems. However, not all developers of hypervisors succeeded (or maybe they did not want to) develop a general concept of using the capabilities of a video card with virtual machines, which was proposed by leading manufacturers of computing graphics modules. There are many holivars on this topic, I will try to do without participating in them and assess the state of things based only on dry facts.
For quite some time now I have been familiar with the Microsoft hypervisor called Hyper-V. It should be noted that this hypervisor with each next generation of the server platform Windows Server is becoming more functional and intuitive to administer. PowerShell adds new cmdlets that make it easy to manage the hypervisor. There is a great opportunity to implement with the help of scripts even such necessary tasks as backing up virtual machines and creating scheduled snapshots in the scheduler without using third-party and rather expensive programs. It’s easy to administer Hyper-V, the performance of the hypervisor is not satisfactory, the list of operating systems that either have installed services for integrating with the hypervisor or have the ability to install such services is constantly growing, or supporting Hyper-V thanks to kernel modules. More recently, the release of FreeBSD 10.0, the first of the BSD systems, which was easily and effortlessly installed as a guest on the Microsoft hypervisor, and which got rid of children's sores, such as the limited size of the virtual hard disk and the ability to use only an outdated network adapter (legacy or emulated), was just recently released. ), whose speed cannot exceed 100Mbit / s, while the physical network adapter is gigabit. In general, as it may seem, the tendency to improve has a very positive trend. That is why we initially started looking for the answer to the question of whether there is the possibility of using a physical video card in the guest operating system Hyper-V. The answer, it seemed to us then, I didn’t take long to wait and after 5 minutes, judging by the articles on the Internet, we were sure that such an opportunity existed and, moreover, it was qualitatively implemented by Hyper-V developers. As it turned out, we were cruelly mistaken, but first things first.
Microsoft proposed RemoteFX technology as a solution, which was originally developed by Calista Technologies, which was later acquired by Microsoft. The technology itself has very significant hardware requirements for both the virtualization server and the video card, which will be further used by the guest operating system through this technology. The requirements are that the server itself must have a CPU with SLAT support (EPT on Intel, NPT / RVI on AMD), but with the GPU it is still more fun. Here are the actual requirements and recommendations voiced by Microsoft itself:
| Rank | Nvidia | AMD |
|---|---|---|
| Best | NVIDIA Grid 1. Grid K1 2. Grid K2 | AMD FirePro series 1. AMD FirePro S10000 2. AMD FirePro S9000 3. AMD FirePro S7000 |
| Better | NVIDIA Quadro 1. Quadro K6000 2. Quadro K5000 | AMD FirePro series 1. AMD FirePro V9800P 2. ATI FirePro V9800 |
| Good | AMD FirePro series 1. ATI FirePro V8800 2. ATI FirePro V7800 3. AMD FirePro V7800P 4. ATI FirePro V5800 |
There are many guides to deploy RemoteFX on Windows Server in the vast web. However, almost none of these articles are talking about the quality application, but basically the article has such a complete meaning: “Raised it, picked it up, it seems to work, it seems that it even moves faster, it seems that even the load on the central processor has been reduced. What was he doing for? The devil knows him. ”
So, I want to tell you about our experience in finding a solution to the problem of expanding the capabilities of virtual machines in 3D graphics processing. We had a rather clearly defined task. We had to make sure that users of remote desktops of a terminal server deployed on the Windows Server 2012 R2 platform were able to at least qualitatively view various 3D drawings and assemblies in specialized viewers, and at most they themselves could no, no, and run various CAD programs.
The initial idea was to deploy RemoteFX on Windows Server 2012R2. No sooner said than done. There was a server platform DELL PowerEdge R720 equipped with two Intel Xeon processors CPU E5-2670 v2 @ 2.50GHz supporting SLAT, as well as an NVIDIA GRID K2 computing graphics module. A Windows Server 2012R2 standard operating system with a graphical shell was installed on the server, the Hyper-V service was deployed and RemoteFX was configured. In fact, then we thought that this was the final solution and RemoteFX technology would completely suit us. However, in the future we learned that Microsoft imposes on technology and significant software requirements that as a guest operating system that can use the 3D graphic adapter RemoteFX, only Windows 7 and 8 operating systems can perform, and only in the Ultimate and Enterprise editions. Not entirely true of course, given that the hypervisor itself, according to its developers, supports a lot of other operating systems.
It became clear that our goal of using a graphics adapter in a virtual terminal server, which is deployed on Windows Server 2012R2, will remain unrealizable. Okay, we are working with what we have. So what do we have? Very little. Just the possibility of installing Windows 7-8 Ultimate-Enterprise as a guest operating system with the ability to connect only one user to them. And even the beautiful RDP Wrapper library is not able to solve this problem. In addition, as we learned from the performance results, RemoteFX’s three-dimensional graphics adapter is practically not able to work with APIs such as OpenGL, which most CAD programs use, and instead fully support Microsoft’s only proprietary development for Windows - Direct3D.
“Support in Windows Server 2012 R2 is provided for DX 11.0, DirectCompute, and C ++ AMP. Most of the latest graphics cards will support OpenGL 4.0 and OpenCL 1.1 or later, but these APIs are currently unsupported by RemoteFX in Windows Server 2012 R2. ”
What is this proprietary development to support the deployment of a terminal server based on virtual machines proposed in the latest generation of Windows Server? It is difficult to answer this question. However, only one thing is clear, RemoteFX technology is not applicable for solving our task, especially in view of the excessively high hardware and software requirements for the platform, server and guest operating systems. Of course, we are ready to satisfy all these requirements, but to end up with a turnkey solution with extremely dubious functionality is a waste.
That is why the search did not stop and, to our shame, the first time we paid attention to what NVIDIA herself writes about the graphic computing module he developed and its application. Read more hereIn short, NVIDIA created NVIDIA GRID vGPU technology, thanks to which the graphic commands of each virtual machine are transmitted directly to the GPU, without broadcast by the hypervisor. Thanks to the driver, one physical graphics module has several virtual GPU profiles with a different number of cores and discrete graphics memory. Here is the table of available virtual profiles for NVIDIA GRID graphics cards:
| NVIDIA GRID Graphics Card | Virtual GPU Profile | Graphic memory | Maximum number of displays per user | Maximum display resolution | Maximum number of users per graphics card |
|---|---|---|---|---|---|
| GRID K2 | K280Q K260Q K240Q K220Q | 4GB 2GB 1GB 512MB | 4 4 2 2 | 2560x1600 2560x1600 2560x1600 2560x1600 | 2 4 8 16 |
| GRID K1 | K180Q K160Q K140Q K120Q | 4GB 2GB 1GB 512MB | 4 2 2 2 | 2560x1600 2560x1600 2560x1600 2560x1600 | 4 8 16 32 |
Everything is extremely simple and beautiful. The driver has the ability to isolate virtual profiles from the hardware platform of the board, which differ from each other in the number of graphic cores and memory, which can become an analogue of a physical video card in a virtual machine. While RemoteFX technology is just a software layer between a virtual machine and a real graphics card, which selectively transfers certain graphics to processing. Why then does Microsoft recommend using a graphics card whose functionality is not fully supported by the capabilities of their hypervisor? Why recommend this board for use if the hypervisor written by them does not follow the path of development of the concept proposed by the manufacturers of the graphics card? Unclear. However, it should be noted that in the description of the NVIDIA GRID VGPU technology on the NVIDIA website,
It was decided to try as a hypervisor XenServer 6.5 from Citrix, whose functionality in the Enterprise edition just supports the distribution of virtual graphic profiles between virtual machines. Although this has nothing to do with the article, I note that installing and configuring the server is simple and intuitive to the point of disgrace. The server was installed and activated with a trial license for 90 days, which can be obtained, taking into account the number of host sockets, in 5 minutes by registering on the developers website. Once activated, the profile sharing feature is available in XenCenter. Unfortunately, drivers exclusively for Windows operating systems are currently available for download, however, it’s good that the graphic profile can be installed not only on Windows 7-8 Ultimate-Enterprise,
To assess the quality of virtual graphic profiles, the guest operating system was Windows 8.1_x64_Enterprise, the first three profiles (K280Q, K260Q, K240Q) were added to the virtual machine settings, which are considered the most productive in descending order, and with each graphic profile 4 benchmarks were launched, testing 3D graphics performance using the OpenGL and Direct3D APIs. So that the comparison does not seem excessively abstract, a decision was made to compare the results of benchmarks running on a VM with the results of the same benchmarks running on a physical machine that has similar characteristics. Briefly about the technical characteristics of the virtual and physical machines can be found in the table below.
| OS | CPU | RAM | Video adapter | |
|---|---|---|---|---|
| Fm | Windows 8.1 x64 Enterprise | Inter Core (TM) CPU i5-4670 @ 3.40GHz | 12GB | Nvidia GeForce GTX 650 |
| VM | Windows 8.1 x64 Enterprise | Inter Xeon CPU E5-2670 v2 @ 2.50GHz | 12GB | Nvidia GRID VGPU K280Q || K260Q || K240Q. |
In the tables with benchmark results, I will indicate only the name of the graphics adapter.
So, the first benchmark will be SPECviewperf 12.0.2, which is revered by many experts as a benchmark for testing graphics of various CAD programs. Who cares, more details here . The results are in the table below. The window resolution is 1900x1060 everywhere (by default in the benchmark).
| Test | GTX 650 | K280Q | K260Q | K240Q |
|---|---|---|---|---|
| Catia-04 | 9.06 | 17.16 | 31.83 | 12.14 |
| Creo-01 | 9.21 | 17.85 | 34.41 | 17.72 |
| Energy-01 | 0.43 | 0.72 | 0.74 | 0.18 |
| Maya-04 | 22.45 | 6.14 | 13.99 | 2.85 |
| Medical-01 | 6.18 | 15.17 | 18.76 | 15.38 |
| Showcase-01 | 14.99 | 11.14 | 32.80 | 10.84 |
| Snx-02 | 2.07 | 18.31 | 34.80 | 18.41 |
| SolidWorks-03 | 20.56 | 02/19 | 38.14 | 20.79 |
I spread all the results as is. I was a little embarrassed that the K260Q profile should in principle be “weaker” than the K280Q, but it showed more outstanding results. I double-checked it by running the test again on both profiles and came to the conclusion that the readings are stable (not random) and although they differ from the original, but within a reasonable range of 0.2-0.4.
The next benchmark, or rather a set of different benchmarks for testing OpenGL graphics, was GpuTest from geeks3d.com, more details can be found here . The results are in the table below in the format (points / FPS). All tests performed in full screen 1920x1080.
| Test | GTX 650 (points / FPS) | K280Q (points / FPS) | K260Q (points / FPS) | K240Q (points / FPS) |
|---|---|---|---|---|
| FurMark (OpenGL 2.1 / 3.0) | 1214/20 | 2068/34 | 1790/29 | 1619/26 |
| GiMark (OpenGL 3.3) | 960/15 | 1630/27 | 1578/26 | 1604/26 |
| PixMark Julia FP32 (OpenGL 2.1 / 3.0) | 6724/111 | 2231/37 | 3874/64 | 3364/56 |
| PixMark Julia FP64 (OpenGL 4.0) | 490/8 | 1046/17 | 1216/20 | 1082/18 |
| Plot3D (OpenGL 2.1 / 3.0) | 39817/664 | 2289/38 | 2299/38 | 2296/38 |
| TessMark x16 (OpenGL 4.0) | 13458/224 | 1545/25 | 1329/22 | 1542/25 |
| TessMark x64 (OpenGL 4.0) | 3039/50 | 1511/25 | 1419/23 | 1535/25 |
| Triangle (OpenGL 2.1 / 3.0) | 145268/2421 | 3748/62 | 3871/64 | 3757/62 |
The next benchmark was the RedSDK turbine benchmark from REDWAY3D. More details here . The results are in the table below. All tests performed in full screen 1920x1080.
| Test | GTX 650 | K280Q | K260Q | K240Q |
|---|---|---|---|---|
| Real-time viewport | 1623 | 1018 | 368 | 400 |
| High quality real-time | 1800 | 1576 | 355 | 366 |
| Dynamic ambient occlusion | 1311 | 2459 | 2378 | 2418 |
| Hybrid ray-tracing | 1114 | 414 | 413 | 399 |
| Total score | 1437 | 1131 | 599 | 614 |
The latest benchmark was the free version of Heaven Benchmark 4.0 from Unigine developers. More details here . The choice fell on him, including because he can test Direct3D graphics. All tests were performed in a window with a resolution of 1280x720 due to the fact that the benchmark did not want to run in full screen mode on virtual machines for reasons unknown to me, giving an error. The results are in the tables below.
| Opengl | GTX 650 | K280Q | K260Q | K240Q |
|---|---|---|---|---|
| Fps | 44.9 | 56.8 | 54.0 | 56.3 |
| Score | 1131 | 1432 | 1361 | 1418 |
| Min fps | 11.2 | 13.2 | 8.8 | 11.8 |
| Max fps | 83.7 | 66.1 | 66.0 | 66.0 |
| Direct3D 11 | GTX 650 | K280Q | K260Q | K240Q |
|---|---|---|---|---|
| Fps | 46.9 | 69.4 | 34.2 | 57.4 |
| Score | 1183 | 1747 | 862 | 1446 |
| Min fps | 10.7 | 9.2 | 6.9 | 9.9 |
| Max fps | 88.1 | 137.5 | 93.8 | 67.5 |
I will not draw any conclusions from the tests I have made; I’d better leave it to the public. To be honest, the test results are not completely clear to me and if the reader has something to comment on qualitatively, I will only be glad.
Summing up, I’ll say that all CAD programs and other software used in our company are successfully installed and run on virtual machines. It remains to give a specialist using these programs to work with remote desktop and let him make a final verdict on the possibility of using this solution. I also want to emphasize that I wrote this article not at all from idleness, but precisely because when I was looking for a solution to the task set by the IT department, I did not see such articles that fully disclose the differences between different technologies for forwarding the capabilities of the graphics card into the virtual machine, I did not see the articles, which describe the quality application of these technologies.
I hope the experience of our IT department is useful to someone. Thank you for attention.