Grid Vgpu User Guide
Grid Vgpu User Guide
User Guide
Figure 18. Verifying NVIDIA driver operation using NVIDIA Control Panel.....................................91
Figure 23. Breadth-first allocation scheme setting for vGPU-enabled VMs............................. 107
Figure 27. Using nvidia-smi from a Windows guest VM to get total resource usage by
all applications........................................................................................................................................................136
Figure 28. Using nvidia-smi from a Windows guest VM to get resource usage by
individual applications........................................................................................................................................ 137
Figure 31. Including NVIDIA logs in a Citrix Hypervisor status report.......................................... 154
Figure 36. Editing a GPU’s enabled vGPU types using XenCenter................................................. 271
NVIDIA vGPU software is a graphics virtualization platform that provides virtual machines
(VMs) access to NVIDIA GPU technology.
Note:
Citrix Hypervisor provides a specific setting to allow the primary display adapter to be
used for GPU pass through deployments.
Only the following GPUs are supported as the primary display adapter:
‣ Tesla M6
‣ Quadro RTX 6000
‣ Quadro RTX 8000
All other GPUs that support NVIDIA vGPU software cannot function as the primary display
adapter because they are 3D controllers, not VGA devices.
If the hypervisor host does not have an extra graphics adapter, consider installing a low-
end display adapter to be used as the primary display adapter. If necessary, ensure that
the primary display adapter is set correctly in the BIOS options of the hypervisor host.
In addition to providing all the benefits of MIG, NVIDIA vGPU software adds virtual
machine security and management for workloads. Single Root I/O Virtualization (SR-
IOV) virtual functions enable full IOMMU protection for the virtual machines that are
configured with vGPUs.
Figure 1 shows a GPU that is split into three GPU instances of different sizes, with
each instance mapped to one vGPU. Although each GPU instance is managed by the
hypervisor host and is mapped to one vGPU, each virtual machine can further subdivide
the compute resources into smaller compute instances and run multiple containers on
top of them in parallel, even within each vGPU.
NVIDIA vGPU software supports a single-slice MIG-backed vGPU with DEC, JPG, and OFA
support. Only one MIG-backed vGPU with DEC, JPG, and OFA support can reside on a
GPU. The instance can be placed identically to a single-slice instance without DEC, JPG,
and OFA support.
Not all hypervisors support GPU instances in NVIDIA vGPU deployments. To determine if
your chosen hypervisor supports GPU instances in NVIDIA vGPU deployments, consult
the release notes for your hypervisor at NVIDIA Virtual GPU Software Documentation.
NVIDIA vGPU software supports GPU instances only with NVIDIA Virtual Compute Server
and Linux guest operating systems.
To support GPU instances with NVIDIA vGPU, a GPU must be configured with MIG mode
enabled and GPU instances must be created and configured on the physical GPU. For
more information, see Configuring a GPU for MIG-Backed vGPUs. For general information
about the MIG feature, see: NVIDIA Multi-Instance GPU User Guide.
Note: These APIs are backwards compatible. Older versions of the API are also supported.
Note:
If you are using NVIDIA vGPU software with CUDA on Linux, avoid conflicting installation
methods by installing CUDA from a distribution-independent runfile package. Do not
install CUDA from a distribution-specific RPM or Deb package.
To ensure that the NVIDIA vGPU software graphics driver is not overwritten when CUDA is
installed, deselect the CUDA driver when selecting the CUDA components to install.
For more information, see NVIDIA CUDA Installation Guide for Linux.
‣ The 8Q vGPU type on Tesla M6, Tesla M10, and Tesla M60 GPUs
‣ All Q-series vGPU types on the following GPUs:
‣ NVIDIA A10
‣ NVIDIA A16
‣ NVIDIA A40
‣ NVIDIA RTX A5000
‣ NVIDIA RTX A6000
‣ Tesla P4
‣ Tesla P6
‣ Tesla P40
‣ Tesla P100 SXM2 16 GB
‣ Tesla P100 PCIe 16 GB
‣ Tesla P100 PCIe 12 GB
‣ Tesla V100 SXM2
‣ Tesla V100 SXM2 32GB
‣ Tesla V100 PCIe
‣ Tesla V100 PCIe 32GB
‣ Tesla V100S PCIe 32GB
‣ Tesla V100 FHHL
‣ Tesla T4
‣ Quadro RTX 6000
‣ Quadro RTX 6000 passive
‣ Quadro RTX 8000
‣ Quadro RTX 8000 passive
‣ All C-series vGPU types
‣ Debuggers:
‣ CUDA-GDB
‣ Compute Sanitizer
‣ Profilers (supported on MIG-backed vGPUs since 13.1):
‣ The Activity, Callback, and Profiling APIs of the CUDA Profiling Tools Interface
(CUPTI)
Other CUPTI APIs, such as the Event and Metric APIs, are not supported.
‣ NVIDIA Nsight™ Compute
‣ NVIDIA Nsight Systems
‣ NVIDIA Nsight plugin
Note: By default, NVIDIA CUDA Toolkit development tools are disabled on NVIDIA vGPU.
If used, you must enable NVIDIA CUDA Toolkit development tools individually for each
VM that requires them by setting vGPU plugin parameters. For instructions, see Enabling
NVIDIA CUDA Toolkit Development Tools for NVIDIA vGPU.
The following table lists the GPUs on which NVIDIA vGPU supports these debuggers and
profilers.
Since 13.1: ✓
Since 13.1: ✓
Since 13.1: ✓
Since 13.1: ✓
Since 13.1: ✓
Since 13.1: ✓
Since 13.1: ✓
Since 13.1: ✓
Since 13.1: ✓
Since 13.1: ✓
Tesla T4 Time-sliced ✓ ✓
Quadro RTX 6000 Time-sliced ✓ ✓
Quadro RTX 6000 Time-sliced ✓ ✓
passive
Quadro RTX 8000 Time-sliced ✓ ✓
Quadro RTX 8000 Time-sliced ✓ ✓
passive
Tesla V100 SXM2 Time-sliced ✓ ✓
Tesla V100 SXM2 Time-sliced ✓ ✓
32GB
Tesla V100 PCIe Time-sliced ✓ ✓
Tesla V100 PCIe 32GB Time-sliced ✓ ✓
Tesla V100S PCIe Time-sliced ✓ ✓
32GB
Tesla V100 FHHL Time-sliced ✓ ✓
✓ Feature is supported
- Feature is not supported
Note: To determine the NVLink topology between physical GPUs in a host or vGPUs
assigned to a VM, run the following command from the host or VM:
$ nvidia-smi topo -m
Note: Unified memory is disabled by default. If used, you must enable unified memory
individually for each vGPU that requires it by setting a vGPU plugin parameter. For
instructions, see Enabling Unified Memory for a vGPU.
Dynamic page retirement is supported for all vGPU types on physical GPUs that support
ECC memory, even if ECC memory is disabled on the physical GPU.
Note: These features, except GPUDirect technology storage, are supported in GPU pass-
through mode and in bare-metal deployments.
‣ This chapter introduces the capabilities and features of NVIDIA vGPU software.
‣ Installing and Configuring NVIDIA Virtual GPU Manager provides a step-by-step guide
to installing and configuring vGPU on supported hypervisors.
‣ Using GPU Pass-Through explains how to configure a GPU for pass-through on
supported hypervisors.
‣ Installing the NVIDIA vGPU Software Graphics Driver explains how to install NVIDIA
vGPU software graphics driver on Windows and Linux operating systems.
‣ Licensing an NVIDIA vGPU explains how to license NVIDIA vGPU licensed products on
Windows and Linux operating systems.
‣ Modifying a VM's NVIDIA vGPU Configuration explains how to remove a VM’s vGPU
configuration and modify GPU assignments for vGPU-enabled VMs.
‣ Monitoring GPU Performance covers performance monitoring of physical GPUs and
virtual GPUs from the hypervisor and from within individual guest VMs.
‣ Changing Scheduling Behavior for Time-Sliced vGPUs describes the scheduling
behavior of NVIDIA vGPUs and how to change it.
‣ Troubleshooting provides guidance on troubleshooting.
‣ Virtual GPU Types Reference provides details of each vGPU available from each
supported GPU and provides examples of mixed virtual display configurations for B-
series and Q-series vGPUs.
‣ Configuring x11vnc for Checking the GPU in a Linux Server explains how to use
x11vnc to confirm that the NVIDIA GPU in a Linux server to which no display devices
are directly connected is working as expected.
‣ Disabling NVIDIA Notification Icon for Citrix Published Application User Sessions
explains how to ensure that the NVIDIA Notification Icon application does not prevent
the Citrix Published Application user session from being logged off even after the
user has quit all ot
‣ Citrix Hypervisor Basics explains how to perform basic operations on Citrix Hypervisor
to install and configure NVIDIA vGPU software and optimize Citrix Hypervisor
operation with vGPU.
‣ Citrix Hypervisor vGPU Management covers vGPU management on Citrix Hypervisor.
‣ Citrix Hypervisor Performance Tuning covers vGPU performance optimization on Citrix
Hypervisor.
The process for installing and configuring NVIDIA Virtual GPU Manager depends on the
hypervisor that you are using. After you complete this process, you can install the display
drivers for your guest OS and license any NVIDIA vGPU software licensed products that
you are using.
Each NVIDIA vGPU is analogous to a conventional GPU, having a fixed amount of GPU
framebuffer, and one or more virtual display outputs or “heads”. The vGPU’s framebuffer
is allocated out of the physical GPU’s framebuffer at the time the vGPU is created, and
the vGPU retains exclusive use of that framebuffer until it is destroyed.
Depending on the physical GPU, different types of vGPU can be created on the vGPU:
‣ On all GPUs that support NVIDIA vGPU software, time-sliced vGPUs can be created.
‣ Additionally, on GPUs that support the Multi-Instance GPU (MIG) feature, MIG-backed
vGPUs can be created. The MIG feature is introduced on GPUs that are based on the
NVIDIA Ampere GPU architecture.
1
NVIDIA vGPUs with less than 1 Gbyte of frame buffer support only 1 virtual display head on a Windows 10 guest OS.
2
C-series vGPU types are NVIDIA Virtual Compute Server vGPU types, which are optimized for compute-intensive
workloads. As a result, they support only a single display head and do not provide Quadro graphics acceleration.
The number after the board type in the vGPU type name denotes the amount of frame
buffer that is allocated to a vGPU of that type. For example, a vGPU of type A16-4C is
allocated 4096 Mbytes of frame buffer on an NVIDIA A16 board.
Due to their differing resource requirements, the maximum number of vGPUs that can be
created simultaneously on a physical GPU varies according to the vGPU type. For example,
an NVDIA A16 board can support up to 4 A16-4C vGPUs on each of its two physical GPUs,
for a total of 16 vGPUs, but only 2 A16-8C vGPUs, for a total of 8 vGPUs.
When enabled, the frame-rate limiter (FRL) limits the maximum frame rate in frames per
second (FPS) for a vGPU as follows:
Note:
NVIDIA vGPU is a licensed product on all supported GPU boards. A software license is
required to enable all vGPU features within the guest VM. The type of license required
depends on the vGPU type.
3
The maximum number of NVIDIA Virtual Compute Server vGPUs is limited to 12 vGPUs per physical GPU, irrespective of
the available hardware resources of the physical GPU.
4
The -1B4 and -2B4 vGPU types are deprecated in this release, and may be removed in a future release. In preparation for
the possible removal of these vGPU types, use the following vGPU types, which provide equivalent functionality:
For details of the virtual GPU types available from each supported GPU, see Virtual GPU
Types for Supported GPUs.
Note: You cannot use more than the maximum number of displays that a vGPU supports
even if the combined resolution of the displays is less than the number of available pixels
from the vGPU. For example, because -0Q and -0B vGPUs support a maximum of only
two displays, you cannot use four 1280×1024 displays with these vGPUs even though the
combined resolution of the displays (6220800) is less than the number of available pixels
from these vGPUs (8192000).
Various factors affect the consumption of the GPU frame buffer, which can impact the
user experience. These factors include and are not limited to the number of displays,
display resolution, workload and applications deployed, remoting solution, and guest OS.
The ability of a vGPU to drive a certain combination of displays does not guarantee that
enough frame buffer remains free for all applications to run. If applications run out of
frame buffer, consider changing your setup in one of the following ways:
‣ A valid configuration with M60-2Q vGPUs on GPU 0 and M60-4Q vGPUs on GPU 1
‣ A valid configuration with M60-1B vGPUs on GPU 0 and M60-2Q vGPUs on GPU 1
‣ An invalid configuration with mixed vGPU types on GPU 0
‣ You have a server platform that is capable of hosting your chosen hypervisor and
NVIDIA GPUs that support NVIDIA vGPU software.
‣ One or more NVIDIA GPUs that support NVIDIA vGPU software is installed in your
server platform.
‣ If you are using GPUs based on the NVIDIA Ampere architecture, the following BIOS
settings are enabled on your server platform:
‣ VT-D/IOMMU
‣ SR-IOV
‣ Alternative Routing ID Interpretation (ARI)
‣ You have downloaded the NVIDIA vGPU software package for your chosen hypervisor,
which consists of the following software:
‣ Your chosen hypervisor, for example, Citrix Hypervisor, Red Hat Enterprise Linux
KVM, Red Hat Virtualization (RHV), or VMware vSphere Hypervisor (ESXi)
‣ The software for managing your chosen hypervisor, for example, Citrix XenCenter
management GUI, or VMware vCenter Server
‣ The virtual desktop software that you will use with virtual machines (VMs) running
NVIDIA Virtual GPU, for example, Citrix Virtual Apps and Desktops, or VMware
Horizon
Note: If you are using VMware vSphere Hypervisor (ESXi), ensure that the ESXi host on
which you will configure a VM with NVIDIA vGPU is not a member of a fully automated
VMware Distributed Resource Scheduler (DRS) cluster. For more information, see
Installing and Configuring the NVIDIA Virtual GPU Manager for VMware vSphere.
Note: If the VM uses UEFI boot and you plan to install a Linux guest OS in the VM,
ensure that secure boot is disabled.
All hypervisors covered in this guide support multiple vGPUs in a VM.
A GPU that is supplied from the factory in displayless mode, such as the NVIDIA A40 GPU,
might be in a display-enabled mode if its mode has previously been changed.
To change the mode of a GPU that supports multiple display modes, use the
displaymodeselector tool, which you can request from the NVIDIA Display Mode
Selector Tool page on the NVIDIA Developer website.
Note:
Only the following GPUs support the displaymodeselector tool:
‣ NVIDIA A40
‣ NVIDIA RTX A5000
Note:
Only Tesla M60 and M6 GPUs support the gpumodeswitch tool. Other GPUs that support
NVIDIA vGPU do not support the gpumodeswitch tool and, except as stated in Switching
the Mode of a GPU that Supports Multiple Display Modes, do not require mode switching.
Even in compute mode, Tesla M60 and M6 GPUs do not support NVIDIA Virtual Compute
Server vGPU types. Furthermore, vCS is not supported on any GPU on Citrix Hypervisor.
CAUTION: NVIDIA Virtual GPU Manager and guest VM drivers must be compatible. If you
update vGPU Manager to a release that is incompatible with the guest VM drivers, guest
VMs will boot with vGPU disabled until their guest vGPU driver is updated to a compatible
version. Consult Virtual GPU Software for Citrix Hypervisor Release Notes for further details.
Note:
You can query the version of the current NVIDIA Virtual GPU Manager package using
the rpm –q command:
[root@xenserver ~]# rpm –q NVIDIA-vGPU-NVIDIA-vGPU-
CitrixHypervisor-8.2-470.223.02
[root@xenserver ~]#
1. Verify that the NVIDIA vGPU software package is installed and loaded correctly by
checking for the NVIDIA kernel driver in the list of kernel loaded modules.
[root@xenserver ~]# lsmod | grep nvidia
nvidia 9522927 0
i2c_core 20294 2 nvidia,i2c_i801
[root@xenserver ~]#
2. Verify that the NVIDIA kernel driver can successfully communicate with the NVIDIA
physical GPUs in your system by running the nvidia-smi command.
The nvidia-smi command is described in more detail in NVIDIA System Management
Interface nvidia-smi.
Running the nvidia-smi command should produce a listing of the GPUs in your platform.
[root@xenserver ~]# nvidia-smi
Fri Nov 10 18:46:50 2023
+------------------------------------------------------+
| NVIDIA-SMI 470.223.02 Driver Version: 470.223.02 |
|-------------------------------+----------------------+----------------------+
+-----------------------------------------------------------------------------+
| Processes: GPU Memory |
| GPU PID Type Process name Usage |
|=============================================================================|
| No running processes found |
+-----------------------------------------------------------------------------+
[root@xenserver ~]#
If nvidia-smi fails to run or doesn’t produce the expected output for all the NVIDIA GPUs
in your system, see Troubleshooting for troubleshooting steps.
Note: If you are using Citrix Hypervisor 8.1 or later and need to assign plugin configuration
parameters, create vGPUs using the xe command as explained in Creating a vGPU Using
xe.
After you have configured a Citrix Hypervisor VM with a vGPU, start the VM, either from
XenCenter or by using xe vm-start in a dom0 shell. You can view the VM’s console in
XenCenter.
After the VM has booted, install the NVIDIA vGPU software graphics driver as explained in
Installing the NVIDIA vGPU Software Graphics Driver.
1. Get the UUIDs of all VMs on the hypervisor host and use the output from the
command to identify the VM to which the vGPU is assigned.
[root@xenserver ~] xe vm-list
...
uuid ( RO) : 7f6c855d-5635-2d57-9fbc-b1200172162f
name-label ( RW): RHEL8.3
power-state ( RO): running
...
2. Get the UUIDs of all vGPUs on the hypervisor host and from the UUID of the VM to
which the vGPU is assigned, determine the UUID of the vGPU.
[root@xenserver ~] xe vgpu-list
...
uuid ( RO) : d15083f8-5c59-7474-d0cb-fbc3f7284f1b
vm-uuid ( RO): 7f6c855d-5635-2d57-9fbc-b1200172162f
device ( RO): 0
gpu-group-uuid ( RO): 3a2fbc36-827d-a078-0b2f-9e869ae6fd93
...
3. Use the xe command to set each vGPU plugin parameter that you want to set.
[root@xenserver ~] xe vgpu-param-set uuid=vgpu-uuid extra_args='parameter=value'
vgpu-uuid
The UUID of the vGPU, which you obtained in the previous step.
parameter
The name of the vGPU plugin parameter that you want to set.
value
The value to which you want to set the vGPU plugin parameter.
This example sets the enable_uvm vGPU plugin parameter to 1 for the vGPU that has
the UUID d15083f8-5c59-7474-d0cb-fbc3f7284f1b. This parameter setting enables
unified memory for the vGPU.
[root@xenserver ~] xe vgpu-param-set uuid=d15083f8-5c59-7474-d0cb-fbc3f7284f1b
extra_args='enable_uvm=1'
Note: If you are using Red Hat Enterprise Linux KVM, follow the instructions in Installing
and Configuring the NVIDIA Virtual GPU Manager for Red Hat Enterprise Linux KVM or
RHV.
Before installing the Virtual GPU Manager package for Linux KVM, ensure that the
following prerequisites are met:
1. Change to the directory on the Linux KVM server that contains the package file.
# cd package-file-directory
package-file-directory
The path to the directory that contains the package file.
2. Make the package file executable.
# chmod +x package-file-name
package-file-name
The name of the file that contains the Virtual GPU Manager package for Linux
KVM, for example NVIDIA-Linux-x86_64-390.42-vgpu-kvm.run.
3. Run the package file as the root user.
# sudo sh./package-file-name
The package file should launch and display the license agreement.
4. Accept the license agreement to continue with the installation.
5. When installation has completed, select OK to exit the installer.
6. Reboot the Linux KVM server.
# systemctl reboot
CAUTION: Output from the VM console is not available for VMs that are running vGPU.
Make sure that you have installed an alternate means of accessing the VM (such as a VNC
server) before you configure vGPU.
Note: If you are using a generic Linux KVM hypervisor, follow the instructions in Installing
the Virtual GPU Manager Package for Linux KVM.
CAUTION: NVIDIA Virtual GPU Manager and guest VM drivers must be compatible. If you
update vGPU Manager to a release that is incompatible with the guest VM drivers, guest
VMs will boot with vGPU disabled until their guest vGPU driver is updated to a compatible
version. Consult Virtual GPU Software for Red Hat Enterprise Linux with KVM Release Notes
for further details.
1. Securely copy the RPM file from the system where you downloaded the file to the Red
Hat Enterprise Linux KVM or RHV server.
1. Verify that the NVIDIA vGPU software package is installed and loaded correctly by
checking for the VFIO drivers in the list of kernel loaded modules.
# lsmod | grep vfio
nvidia_vgpu_vfio 27099 0
nvidia 12316924 1 nvidia_vgpu_vfio
vfio_mdev 12841 0
mdev 20414 2 vfio_mdev,nvidia_vgpu_vfio
vfio_iommu_type1 22342 0
vfio 32331 3 vfio_mdev,nvidia_vgpu_vfio,vfio_iommu_type1
#
2. Verify that the libvirtd service is active and running.
# service libvirtd status
3. Verify that the NVIDIA kernel driver can successfully communicate with the NVIDIA
physical GPUs in your system by running the nvidia-smi command.
The nvidia-smi command is described in more detail in NVIDIA System Management
Interface nvidia-smi.
Running the nvidia-smi command should produce a listing of the GPUs in your platform.
# nvidia-smi
Fri Nov 10 18:46:50 2023
+------------------------------------------------------+
| NVIDIA-SMI 470.223.02 Driver Version: 470.223.02 |
|-------------------------------+----------------------+----------------------+
| GPU Name Persistence-M| Bus-Id Disp.A | Volatile Uncorr. ECC |
If nvidia-smi fails to run or doesn’t produce the expected output for all the NVIDIA GPUs
in your system, see Troubleshooting for troubleshooting steps.
1. Determine the mediated device type (mdev_type) identifiers of the vGPU types
available on the RHV host.
# vdsm-client Host hostdevListByCaps
...
"mdev": {
"nvidia-155": {
"name": "GRID M10-2B",
"available_instances": "4"
},
"nvidia-36": {
"name": "GRID M10-0Q",
"available_instances": "16"
},
...
The preceding example shows the mdev_type identifiers of the following vGPU types:
‣ For the GRID M10-2B vGPU type, the mdev_type identifier is nvidia-155.
‣ For the GRID M10-0Q vGPU type, the mdev_type identifier is nvidia-36.
2. Note the mdev_type identifier of the vGPU type that you want to add.
3. Log in to the RHV Administration Portal.
4. From the Main Navigation Menu, choose Compute > Virtual Machines > virtual-
machine-name .
virtual-machine-name
The name of the virtual machine to which you want to add the vGPU.
5. Click Edit.
6. In the Edit Virtual Machine window that opens, click Show Advanced Options and in
the list of options, select Custom Properties.
7. From the drop-down list, select mdev_type.
8. In the text field, type the mdev_type identifier of the vGPU type that you want to add
and click OK.
CAUTION: Output from the VM console is not available for VMs that are running vGPU.
Make sure that you have installed an alternate means of accessing the VM (such as a VNC
server) before you configure vGPU.
After the process is complete, you can install the graphics driver for your guest OS and
license any NVIDIA vGPU software licensed products that you are using.
CAUTION: NVIDIA Virtual GPU Manager and guest VM drivers must be compatible. If you
update vGPU Manager to a release that is incompatible with the guest VM drivers, guest
VMs will boot with vGPU disabled until their guest vGPU driver is updated to a compatible
version. Consult Virtual GPU Software for Ubuntu Release Notes for further details.
1. Securely copy the Debian package file from the system where you downloaded the file
to the Ubuntu server.
1. Verify that the NVIDIA vGPU software package is installed and loaded correctly by
checking for the VFIO drivers in the list of kernel loaded modules.
# lsmod | grep vfio
nvidia_vgpu_vfio 27099 0
nvidia 12316924 1 nvidia_vgpu_vfio
vfio_mdev 12841 0
mdev 20414 2 vfio_mdev,nvidia_vgpu_vfio
vfio_iommu_type1 22342 0
vfio 32331 3 vfio_mdev,nvidia_vgpu_vfio,vfio_iommu_type1
#
2. Verify that the libvirtd service is active and running.
# service libvirtd status
3. Verify that the NVIDIA kernel driver can successfully communicate with the NVIDIA
physical GPUs in your system by running the nvidia-smi command.
The nvidia-smi command is described in more detail in NVIDIA System Management
Interface nvidia-smi.
Running the nvidia-smi command should produce a listing of the GPUs in your platform.
# nvidia-smi
Fri Nov 10 18:46:50 2023
+------------------------------------------------------+
| NVIDIA-SMI 470.223.02 Driver Version: 470.223.02 |
|-------------------------------+----------------------+----------------------+
| GPU Name Persistence-M| Bus-Id Disp.A | Volatile Uncorr. ECC |
| Fan Temp Perf Pwr:Usage/Cap| Memory-Usage | GPU-Util Compute M. |
|===============================+======================+======================|
| 0 Tesla M60 On | 0000:85:00.0 Off | Off |
| N/A 23C P8 23W / 150W | 13MiB / 8191MiB | 0% Default |
+-------------------------------+----------------------+----------------------+
| 1 Tesla M60 On | 0000:86:00.0 Off | Off |
| N/A 29C P8 23W / 150W | 13MiB / 8191MiB | 0% Default |
+-------------------------------+----------------------+----------------------+
| 2 Tesla P40 On | 0000:87:00.0 Off | Off |
| N/A 21C P8 18W / 250W | 53MiB / 24575MiB | 0% Default |
+-------------------------------+----------------------+----------------------+
+-----------------------------------------------------------------------------+
| Processes: GPU Memory |
| GPU PID Type Process name Usage |
|=============================================================================|
| No running processes found |
+-----------------------------------------------------------------------------+
#
If nvidia-smi fails to run or doesn’t produce the expected output for all the NVIDIA GPUs
in your system, see Troubleshooting for troubleshooting steps.
Note:
Some servers, for example, the Dell R740, do not configure SR-IOV capability if the SR-IOV
SBIOS setting is disabled on the server. If you are using the Tesla T4 GPU with VMware
vSphere on such a server, you must ensure that the SR-IOV SBIOS setting is enabled on
the server.
However, with any server hardware, do not enable SR-IOV in VMware vCenter Server
for the Tesla T4 GPU. If SR-IOV is enabled in VMware vCenter Server for T4, VMware
vCenter Server lists the status of the GPU as needing a reboot. You can ignore this status
message.
Note: As of VMware vSphere 7.0 Update 1, the Xorg service is no longer required for
graphics devices in NVIDIA vGPU mode. For more information, see Installing and Updating
the NVIDIA Virtual GPU Manager for vSphere.
‣ For any supported VMware vSphere release, set the automation level to Manual.
‣ For VMware vSphere 6.7 Update 1 or later, set the automation level to Partially
Automated or Manual.
For more information about these settings, see Edit Cluster Settings in the VMware
documentation.
‣ For all supported VMware vSphere releases, the NVIDIA Virtual GPU Manager package
is distributed as a software component in a ZIP archive, which you can install in one of
the following ways:
‣ By copying the software component to the ESXi host and then installing it as
explained in Installing the NVIDIA Virtual GPU Manager Package for vSphere
‣ By importing the software component manually as explained in Import Patches
Manually in the VMware vSphere documentation
‣ For supported releases before VMware vSphere 7.0, the NVIDIA Virtual GPU Manager
package is also distributed as a vSphere Installation Bundle (VIB) file, which you must
copy to the ESXi host and then install as explained in Installing the NVIDIA Virtual GPU
Manager Package for vSphere.
CAUTION: NVIDIA Virtual GPU Manager and guest VM drivers must be compatible. If
you update vGPU Manager to a release that is incompatible with the guest VM drivers,
guest VMs will boot with vGPU disabled until their guest vGPU driver is updated to a
compatible version. Consult Virtual GPU Software for VMware vSphere Release Notes for
further details.
‣ The ZIP archive that contains NVIDIA vGPU software has been downloaded from the
NVIDIA Licensing Portal.
‣ The NVIDIA Virtual GPU Manager package has been extracted from the downloaded
ZIP archive.
1. Copy the NVIDIA Virtual GPU Manager package file to the ESXi host.
2. Put the ESXi host into maintenance mode.
$ esxcli system maintenanceMode set –-enable true
3. Use the esxcli command to install the vGPU Manager package.
For more information about the esxcli command, see esxcli software Commands in
the VMware vSphere documentation.
CAUTION: Do not perform this task on a system where an existing version isn't already
installed. If you perform this task on a system where an existing version isn't already
installed, the Xorg service (when required) fails to start after the NVIDIA vGPU software
driver is installed. Instead, install the vGPU Manager VIB package as explained in Installing
the NVIDIA Virtual GPU Manager Package for vSphere.
To update the vGPU Manager VIB you need to access the ESXi host via the ESXi Shell or
SSH. Refer to VMware’s documentation on how to enable ESXi Shell or SSH for an ESXi
host.
Note: Before proceeding with the vGPU Manager update, make sure that all VMs are
powered off and the ESXi host is placed in maintenance mode. Refer to VMware’s
documentation on how to place an ESXi host in maintenance mode
Installation Result
Message: Operation finished successfully.
Reboot Required: false
VIBs Installed: NVIDIA-vGPU-
VMware_ESXi_7.0_Host_Driver_470.223.02-1OEM.700.0.0.8169922
VIBs Removed: NVIDIA-vGPU-
VMware_ESXi_7.0_Host_Driver_470.199.03-1OEM.700.0.0.8169922
VIBs Skipped:
directory is the path to the directory that contains the VIB file.
2. Reboot the ESXi host and remove it from maintenance mode.
1. Verify that the NVIDIA vGPU software package installed and loaded correctly by
checking for the NVIDIA kernel driver in the list of kernel loaded modules.
[root@esxi:~] vmkload_mod -l | grep nvidia
nvidia 5 8420
2. If the NVIDIA driver is not listed in the output, check dmesg for any load-time errors
reported by the driver.
3. Verify that the NVIDIA kernel driver can successfully communicate with the NVIDIA
physical GPUs in your system by running the nvidia-smi command.
The nvidia-smi command is described in more detail in NVIDIA System Management
Interface nvidia-smi.
Running the nvidia-smi command should produce a listing of the GPUs in your platform.
[root@esxi:~] nvidia-smi
Fri Nov 10 17:56:22 2023
+------------------------------------------------------+
| NVIDIA-SMI 470.223.02 Driver Version: 470.223.02 |
|-------------------------------+----------------------+----------------------+
| GPU Name Persistence-M| Bus-Id Disp.A | Volatile Uncorr. ECC |
| Fan Temp Perf Pwr:Usage/Cap| Memory-Usage | GPU-Util Compute M. |
|===============================+======================+======================|
| 0 Tesla M60 On | 00000000:05:00.0 Off | Off |
| N/A 25C P8 24W / 150W | 13MiB / 8191MiB | 0% Default |
+-------------------------------+----------------------+----------------------+
| 1 Tesla M60 On | 00000000:06:00.0 Off | Off |
| N/A 24C P8 24W / 150W | 13MiB / 8191MiB | 0% Default |
+-------------------------------+----------------------+----------------------+
| 2 Tesla M60 On | 00000000:86:00.0 Off | Off |
| N/A 25C P8 25W / 150W | 13MiB / 8191MiB | 0% Default |
+-------------------------------+----------------------+----------------------+
| 3 Tesla M60 On | 00000000:87:00.0 Off | Off |
| N/A 28C P8 24W / 150W | 13MiB / 8191MiB | 0% Default |
+-------------------------------+----------------------+----------------------+
+-----------------------------------------------------------------------------+
| Processes: GPU Memory |
| GPU PID Type Process name Usage |
|=============================================================================|
| No running processes found |
+-----------------------------------------------------------------------------+
If nvidia-smi fails to report the expected output for all the NVIDIA GPUs in your system,
see Troubleshooting for troubleshooting steps.
Note: Ensure that you select the vCenter Server instance, not the vCenter Server VM.
Note:
If you are using a supported version of VMware vSphere earlier than 6.5, or are configuring
a VM to use vSGA, omit this task.
Change the default graphics type before configuring vGPU. Output from the VM console
in the VMware vSphere Web Client is not available for VMs that are running vGPU.
Before changing the default graphics type, ensure that the ESXi host is running and that
all VMs on the host are powered off.
5. In the Edit Host Graphics Settings dialog box that opens, select Shared Direct and
click OK.
Note: In this dialog box, you can also change the allocation scheme for vGPU-enabled
VMs. For more information, see Modifying GPU Allocation Policy on VMware vSphere.
After you click OK, the default graphics type changes to Shared Direct.
6. Click the Graphics Devices tab to verify the configured type of each physical GPU on
which you want to configure vGPU.
The configured type of each physical GPU must be Shared Direct. For any physical
GPU for which the configured type is Shared, change the configured type as follows:
a). On the Graphics Devices tab, select the physical GPU and click the Edit icon.
b). In the Edit Graphics Device Settings dialog box that opens, select Shared Direct
and click OK.
7. Restart the ESXi host or stop and restart the Xorg service if necessary and nv-
hostengine on the ESXi host.
To stop and restart the Xorg service and nv-hostengine, perform these steps:
a). VMware vSphere releases before 7.0 Update 1 only: Stop the Xorg service.
As of VMware vSphere 7.0 Update 1, the Xorg service is no longer required for
graphics devices in NVIDIA vGPU mode.
b). Stop nv-hostengine.
[root@esxi:~] nv-hostengine -t
c). Wait for 1 second to allow nv-hostengine to stop.
d). Start nv-hostengine.
[root@esxi:~] nv-hostengine -d
e). VMware vSphere releases before 7.0 Update 1 only: Start the Xorg service.
As of VMware vSphere 7.0 Update 1, the Xorg service is no longer required for
graphics devices in NVIDIA vGPU mode.
[root@esxi:~] /etc/init.d/xorg start
8. In the Graphics Devices tab of the VMware vCenter Web UI, confirm that the active
type and the configured type of each physical GPU are Shared Direct.
After changing the default graphics type, configure vGPU as explained in Configuring a
vSphere VM with NVIDIA vGPU.
See also the following topics in the VMware vSphere documentation:
If you are adding multiple vGPUs to a single VM, perform this task for each vGPU that you
want to add to the VM.
CAUTION: Output from the VM console in the VMware vSphere Web Client is not available
for VMs that are running vGPU. Make sure that you have installed an alternate means of
accessing the VM (such as VMware Horizon or a VNC server) before you configure vGPU.
VM console in vSphere Web Client will become active again once the vGPU parameters
are removed from the VM’s configuration.
Note: If you are configuring a VM to use VMware vSGA, omit this task.
5. From the GPU Profile drop-down menu, choose the type of vGPU you want to
configure and click OK.
Note: VMware vSphere does not support vCS. Therefore, C-series vGPU types are not
available for selection from the GPU Profile drop-down menu.
6. Ensure that VMs running vGPU have all their memory reserved:
a). Select Edit virtual machine settings from the vCenter Web UI.
b). Expand the Memory section and click Reserve all guest memory (All locked).
After you have configured a vSphere VM with a vGPU, start the VM. VM console in
vSphere Web Client is not supported in this vGPU release. Therefore, use VMware Horizon
or VNC to access the VM’s desktop.
After the VM has booted, install the NVIDIA vGPU software graphics driver as explained in
Installing the NVIDIA vGPU Software Graphics Driver.
‣ pciPassthru0.cfg.parameter
‣ pciPassthru1.cfg.parameter
parameter
The name of the vGPU plugin parameter that you want to set. For example, the
name of the vGPU plugin parameter for enabling unified memory is enable_uvm.
To enable unified memory for two vGPUs that are assigned to a VM, set
pciPassthru0.cfg.enable_uvm and pciPassthru1.cfg.enable_uvm to 1.
Note: If you are configuring a VM to use NVIDIA vGPU, omit this task.
Before configuring a vSphere VM with vSGA, ensure that these prerequisites are met:
The output from the command is similar to the following example for a VM named
samplevm1:
Xserver unix:0, GPU maximum memory 4173824KB
pid 21859, VM samplevm1, reserved 131072KB of GPU memory.
GPU memory left 4042752KB.
The memory reserved for the VM and the GPU maximum memory depend on the
GPU installed in the host and the 3D memory allocated to the virtual machine.
Installation of the NVIDIA vGPU software graphics driver for the guest OS is not required
for vSGA.
The NVIDIA GPUs listed in this example have the PCI device BDFs 06:00.0 and
07:00.0.
# lspci | grep NVIDIA
06:00.0 VGA compatible controller: NVIDIA Corporation GM204GL [Tesla M10] (rev
a1)
07:00.0 VGA compatible controller: NVIDIA Corporation GM204GL [Tesla M10] (rev
a1)
2. Obtain the full identifier of the GPU from its PCI device BDF.
# virsh nodedev-list --cap pci| grep transformed-bdf
transformed-bdf
The PCI device BDF of the GPU with the colon and the period replaced with
underscores, for example, 06_00_0.
This example obtains the full identifier of the GPU with the PCI device BDF 06:00.0.
# virsh nodedev-list --cap pci| grep 06_00_0
pci_0000_06_00_0
3. Obtain the domain, bus, slot, and function of the GPU from the full identifier of the
GPU.
virsh nodedev-dumpxml full-identifier| egrep 'domain|bus|slot|function'
full-identifier
The full identifier of the GPU that you obtained in the previous step, for example,
pci_0000_06_00_0.
This example obtains the domain, bus, slot, and function of the GPU with the PCI
device BDF 06:00.0.
# virsh nodedev-dumpxml pci_0000_06_00_0| egrep 'domain|bus|slot|function'
<domain>0x0000</domain>
<bus>0x06</bus>
<slot>0x00</slot>
<function>0x0</function>
An mdev device file for the vGPU is added to the parent physical device directory of
the vGPU. The vGPU is identified by its UUID.
The /sys/bus/mdev/devices/ directory contains a symbolic link to the mdev device
file.
6. Make the mdev device file that you created to represent the vGPU persistent.
# mdevctl define --auto --uuid uuid
uuid
The UUID that you specified in the previous step for the vGPU that you are
creating.
Note: Not all Linux with KVM hypervisor releases include the mdevctl command. If
your release does not include the mdevctl command, you can use standard features of
the operating system to automate the re-creation of this device file when the host is
booted. For example, you can write a custom script that is executed when the host is
rebooted.
b). If your release includes the mdevctl command, list the active mediated devices on
the hypervisor host.
# mdevctl list
aa618089-8b16-4d01-a136-25a0f3c73123 0000:06:00.0 nvidia-41
1. Enable the virtual functions for the physical GPU in the sysfs file system.
Note:
‣ Before performing this step, ensure that the GPU is not being used by any other
processes, such as CUDA applications, monitoring applications, or the nvidia-smi
command.
‣ The virtual functions for the physical GPU in the sysfs file system are disabled
after the hypervisor host is rebooted or if the driver is reloaded or upgraded.
Use only the custom script sriov-manage provided by NVIDIA vGPU software for this
purpose. Do not try to enable the virtual function for the GPU by any other means.
# /usr/lib/nvidia/sriov-manage -e domain:bus:slot.function
domain
bus
slot
function
The domain, bus, slot, and function of the GPU, without the 0x prefix.
Note: Only one mdev device file can be created on a virtual function.
This example enables the virtual functions for the GPU with the domain 00, bus 41,
slot 0000, and function 0.
# /usr/lib/nvidia/sriov-manage -e 00:41:0000.0
2. Obtain the domain, bus, slot, and function of the available virtual functions on the
GPU.
# ls -l /sys/bus/pci/devices/domain\:bus\:slot.function/ | grep virtfn
domain
bus
slot
function
The domain, bus, slot, and function of the GPU, without the 0x prefix.
This example shows the output of this command for a physical GPU with slot 00, bus
41, domain 0000, and function 0.
# ls -l /sys/bus/pci/devices/0000:41:00.0/ | grep virtfn
lrwxrwxrwx. 1 root root 0 Jul 16 04:42 virtfn0 -> ../0000:41:00.4
lrwxrwxrwx. 1 root root 0 Jul 16 04:42 virtfn1 -> ../0000:41:00.5
lrwxrwxrwx. 1 root root 0 Jul 16 04:42 virtfn10 -> ../0000:41:01.6
lrwxrwxrwx. 1 root root 0 Jul 16 04:42 virtfn11 -> ../0000:41:01.7
subdirectory
The subdirectory that you found in the previous step, for example, nvidia-558.
The number of available instances must be 1. If the number is 0, a vGPU has already
been created on the virtual function. Only one instance of any vGPU type can be
created on a virtual function.
This example shows that an instance of the A40-2Q vGPU type can be created on the
virtual function.
# cat nvidia-558/available_instances
1
7. Generate a correctly formatted universally unique identifier (UUID) for the vGPU.
# uuidgen
aa618089-8b16-4d01-a136-25a0f3c73123
8. Write the UUID that you obtained in the previous step to the create file in the
registration information directory for the vGPU type that you want to create.
# echo "uuid"> subdirectory/create
uuid
The UUID that you generated in the previous step, which will become the UUID of
the vGPU that you want to create.
subdirectory
The registration information directory for the vGPU type that you want to create,
for example, nvidia-558.
This example creates an instance of the A40-2Q vGPU type with the UUID
aa618089-8b16-4d01-a136-25a0f3c73123.
# echo "aa618089-8b16-4d01-a136-25a0f3c73123" > nvidia-558/create
An mdev device file for the vGPU is added to the parent virtual function directory of
the vGPU. The vGPU is identified by its UUID.
9. Time-sliced vGPUs only: Make the mdev device file that you created to represent the
vGPU persistent.
# mdevctl define --auto --uuid uuid
uuid
The UUID that you specified in the previous step for the vGPU that you are
creating.
Note:
‣ If you are using a GPU that supports SR-IOV, the mdev device file persists after a
host reboot only if you perform Step 1 before rebooting any VM that is configured
with a vGPU on the GPU.
‣ You cannot use the mdevctl command to make the mdev device file for a MIG-
backed vGPU persistent. The mdev device file for a MIG-backed vGPU is not
retained after the host is rebooted because MIG instances are no longer available.
‣ Not all Linux with KVM hypervisor releases include the mdevctl command. If your
release does not include the mdevctl command, you can use standard features of
the operating system to automate the re-creation of this device file when the host
is booted. For example, you can write a custom script that is executed when the
host is rebooted.
2. For each vGPU that you want to add to the VM, add a device entry in the form of an
address element inside the source element to add the vGPU to the guest VM.
<device>
...
<hostdev mode='subsystem' type='mdev' model='vfio-pci'>
<source>
<address uuid='uuid'/>
</source>
</hostdev>
</device>
uuid
The UUID that was assigned to the vGPU when the vGPU was created.
This example adds a device entry for the vGPU with the UUID a618089-8b16-4d01-
a136-25a0f3c73123.
<device>
...
<hostdev mode='subsystem' type='mdev' model='vfio-pci'>
<source>
<address uuid='a618089-8b16-4d01-a136-25a0f3c73123'/>
</source>
</hostdev>
</device>
This example adds device entries for two vGPUs with the following UUIDs:
‣ c73f1fa6-489e-4834-9476-d70dabd98c40
‣ 3b356d38-854e-48be-b376-00c72c7d119c
<device>
...
<hostdev mode='subsystem' type='mdev' model='vfio-pci'>
<source>
<address uuid='c73f1fa6-489e-4834-9476-d70dabd98c40'/>
</source>
</hostdev>
<hostdev mode='subsystem' type='mdev' model='vfio-pci'>
<source>
<address uuid='3b356d38-854e-48be-b376-00c72c7d119c'/>
</source>
</hostdev>
</device>
3. Optional: Add a video element that contains a model element in which the type
attribute is set to none.
<video>
<model type='none'/>
</video>
Adding this video element prevents the default video device that libvirt adds from
being loaded into the VM. If you don't add this video element, you must configure the
Xorg server or your remoting solution to load only the vGPU devices you added and
not the default video device.
‣ For each vGPU that you want to add to the VM, add one -device option in the
following format:
-device vfio-pci,sysfsdev=/sys/bus/mdev/devices/vgpu-uuid
vgpu-uuid
The UUID that was assigned to the vGPU when the vGPU was created.
‣ Add a -uuid option to specify the VM as follows:
-uuid vm-uuid
vm-uuid
The UUID that was assigned to the VM when the VM was created.
This example adds the vGPU with the UUID aa618089-8b16-4d01-a136-25a0f3c73123
to the VM with the UUID ebb10a6e-7ac9-49aa-af92-f56bb8c65893.
-device vfio-pci,sysfsdev=/sys/bus/mdev/devices/aa618089-8b16-4d01-
a136-25a0f3c73123 \
-uuid ebb10a6e-7ac9-49aa-af92-f56bb8c65893
This example adds device entries for two vGPUs with the following UUIDs:
‣ 676428a0-2445-499f-9bfd-65cd4a9bd18f
‣ 6c5954b8-5bc1-4769-b820-8099fe50aaba
1. Change to the nvidia subdirectory of the mdev device directory that represents the
vGPU.
# cd /sys/bus/mdev/devices/uuid/nvidia
uuid
The UUID of the vGPU, for example, aa618089-8b16-4d01-a136-25a0f3c73123.
2. Write the plugin parameters that you want to set to the vgpu_params file in the
directory that you changed to in the previous step.
# echo "plugin-config-params" > vgpu_params
plugin-config-params
A comma-separated list of parameter-value pairs, where each pair is of the form
parameter-name=value.
This example disables frame rate limiting and console VNC for a vGPU.
# echo "frame_rate_limiter=0, disable_vnc=1" > vgpu_params
To clear any vGPU plugin parameters that were set previously, write a space to the
vgpu_params file for the vGPU.
# echo " " > vgpu_params
‣ You have the domain, bus, slot, and function of the GPU where the vGPU that you
want to delete resides. For instructions, see Getting the BDF and Domain of a GPU on
a Linux with KVM Hypervisor.
‣ The VM to which the vGPU is assigned is shut down.
1. Change to the mdev_supported_types directory for the physical GPU.
# cd /sys/class/mdev_bus/domain\:bus\:slot.function/mdev_supported_types/
domain
bus
slot
function
The domain, bus, slot, and function of the GPU, without the 0x prefix.
This example changes to the mdev_supported_types directory for the GPU with the
PCI device BDF 06:00.0.
# cd /sys/bus/pci/devices/0000\:06\:00.0/mdev_supported_types/
2. Change to the subdirectory of mdev_supported_types that contains registration
information for the vGPU.
Note: On the Red Hat Virtualization (RHV) kernel, if you try to remove a vGPU device
while its VM is running, the vGPU device might not be removed even if the remove file
has been written to successfully. To confirm that the vGPU device is removed, confirm
that the UUID of the vGPU is not found in the sysfs file system.
Before you begin, ensure that you have the domain, bus, slot, and function of the GPU
that you are preparing for use with vGPU. For instructions, see Getting the BDF and
Domain of a GPU on a Linux with KVM Hypervisor.
1. Determine the kernel module to which the GPU is bound by running the lspci
command with the -k option on the NVIDIA GPUs on your host.
# lspci -d 10de: -k
The Kernel driver in use: field indicates the kernel module to which the GPU is
bound.
The following example shows that the NVIDIA Tesla M60 GPU with BDF 06:00.0 is
bound to the vfio-pci kernel module and is being used for GPU pass through.
06:00.0 VGA compatible controller: NVIDIA Corporation GM204GL [Tesla M60] (rev
a1)
Subsystem: NVIDIA Corporation Device 115e
Kernel driver in use: vfio-pci
2. Unbind the GPU from vfio-pci kernel module.
a). Change to the sysfs directory that represents the vfio-pci kernel module.
# cd /sys/bus/pci/drivers/vfio-pci
b). Write the domain, bus, slot, and function of the GPU to the unbind file in this
directory.
You can now configure the GPU with vGPU as explained in Installing and Configuring the
NVIDIA Virtual GPU Manager for Red Hat Enterprise Linux KVM or RHV.
All physical GPUs on the host are registered with the mdev kernel module. Information
about the physical GPUs and the vGPU types that can be created on each physical GPU is
stored in directories and files under the /sys/class/mdev_bus/ directory.
The sysfs directory for each physical GPU is at the following locations:
‣ /sys/bus/pci/devices/
‣ /sys/class/mdev_bus/
Both directories are a symbolic link to the real directory for PCI devices in the sysfs file
system.
The organization the sysfs directory for each physical GPU is as follows:
/sys/class/mdev_bus/
|-parent-physical-device
|-mdev_supported_types
|-nvidia-vgputype-id
|-available_instances
|-create
|-description
|-device_api
|-devices
|-name
parent-physical-device
Each physical GPU on the host is represented by a subdirectory of the /sys/class/
mdev_bus/ directory.
The name of each subdirectory is as follows:
domain\:bus\:slot.function
domain, bus, slot, function are the domain, bus, slot, and function of the GPU, for
example, 0000\:06\:00.0.
Each directory is a symbolic link to the real directory for PCI devices in the sysfs file
system. For example:
# ll /sys/class/mdev_bus/
total 0
lrwxrwxrwx. 1 root root 0 Dec 12 03:20 0000:05:00.0 -> ../../devices/
pci0000:00/0000:00:03.0/0000:03:00.0/0000:04:08.0/0000:05:00.0
lrwxrwxrwx. 1 root root 0 Dec 12 03:20 0000:06:00.0 -> ../../devices/
pci0000:00/0000:00:03.0/0000:03:00.0/0000:04:09.0/0000:06:00.0
lrwxrwxrwx. 1 root root 0 Dec 12 03:20 0000:07:00.0 -> ../../devices/
pci0000:00/0000:00:03.0/0000:03:00.0/0000:04:10.0/0000:07:00.0
lrwxrwxrwx. 1 root root 0 Dec 12 03:20 0000:08:00.0 -> ../../devices/
pci0000:00/0000:00:03.0/0000:03:00.0/0000:04:11.0/0000:08:00.0
mdev_supported_types
A directory named mdev_supported_types is required under the sysfs directory for
each physical GPU that will be configured with NVIDIA vGPU. How this directory is
created for a GPU depends on whether the GPU supports SR-IOV.
‣ For a GPU that does not support SR-IOV, this directory is created automatically
after the Virtual GPU Manager is installed on the host and the host has been
rebooted.
‣ For a GPU that supports SR-IOV, such as a GPU based on the NVIDIA Ampere
architecture, you must create this directory by enabling the virtual function for the
GPU as explained in Creating an NVIDIA vGPU on a Linux with KVM Hypervisor. The
mdev_supported_types directory itself is never visible on the physical function.
The mdev_supported_types directory contains a subdirectory for each vGPU type that
the physical GPU supports. The name of each subdirectory is nvidia-vgputype-id,
where vgputype-id is an unsigned integer serial number. For example:
# ll mdev_supported_types/
total 0
drwxr-xr-x 3 root root 0 Dec 6 01:37 nvidia-35
drwxr-xr-x 3 root root 0 Dec 5 10:43 nvidia-36
drwxr-xr-x 3 root root 0 Dec 5 10:43 nvidia-37
drwxr-xr-x 3 root root 0 Dec 5 10:43 nvidia-38
drwxr-xr-x 3 root root 0 Dec 5 10:43 nvidia-39
drwxr-xr-x 3 root root 0 Dec 5 10:43 nvidia-40
drwxr-xr-x 3 root root 0 Dec 5 10:43 nvidia-41
drwxr-xr-x 3 root root 0 Dec 5 10:43 nvidia-42
drwxr-xr-x 3 root root 0 Dec 5 10:43 nvidia-43
drwxr-xr-x 3 root root 0 Dec 5 10:43 nvidia-44
drwxr-xr-x 3 root root 0 Dec 5 10:43 nvidia-45
nvidia-vgputype-id
Each directory represents an individual vGPU type and contains the following files and
directories:
available_instances
This file contains the number of instances of this vGPU type that can still be
created. This file is updated any time a vGPU of this type is created on or removed
from the physical GPU.
create
This file is used for creating a vGPU instance. A vGPU instance is created by writing
the UUID of the vGPU to this file. The file is write only.
description
This file contains the following details of the vGPU type:
‣ The maximum number of virtual display heads that the vGPU type supports
‣ The frame rate limiter (FRL) configuration in frames per second
‣ The frame buffer size in Mbytes
‣ The maximum resolution per display head
‣ The maximum number of vGPU instances per physical GPU
For example:
# cat description
num_heads=4, frl_config=60, framebuffer=2048M, max_resolution=4096x2160,
max_instance=4
device_api
This file contains the string vfio_pci to indicate that a vGPU is a PCI device.
devices
This directory contains all the mdev devices that are created for the vGPU type. For
example:
# ll devices
total 0
lrwxrwxrwx 1 root root 0 Dec 6 01:52 aa618089-8b16-4d01-a136-25a0f3c73123 -
> ../../../aa618089-8b16-4d01-a136-25a0f3c73123
name
This file contains the name of the vGPU type. For example:
# cat name
GRID M10-2Q
Note: For VMware vSphere, only enabling MIG mode is required because VMware
vSphere creates the GPU instances and, after the VM is booted and guest driver is
installed, one compute instance is automatically created in the VM.
1. Open a command shell as the root user on your hypervisor host machine.
On all supported hypervisors, you can use secure shell (SSH) for this purpose.
Individual hypervisors may provide additional means for logging in. For details, refer to
the documentation for your hypervisor.
2. Determine whether MIG mode is enabled.
Use the nvidia-smi command for this purpose. By default, MIG mode is disabled.
This example shows that MIG mode is disabled on GPU 0.
Note: In the output from nvidia-smi, the NVIDIA A100 HGX 40GB GPU is referred to
as A100-SXM4-40GB.
$ nvidia-smi -i 0
+-----------------------------------------------------------------------------+
| NVIDIA-SMI 470.223.02 Driver Version: 470.223.02 CUDA Version: 11.4 |
|-------------------------------+----------------------+----------------------+
| GPU Name Persistence-M| Bus-Id Disp.A | Volatile Uncorr. ECC |
| Fan Temp Perf Pwr:Usage/Cap| Memory-Usage | GPU-Util Compute M. |
| | | MIG M. |
|===============================+======================+======================|
| 0 A100-SXM4-40GB On | 00000000:36:00.0 Off | 0 |
| N/A 29C P0 62W / 400W | 0MiB / 40537MiB | 6% Default |
| | | Disabled |
+-------------------------------+----------------------+----------------------+
3. If MIG mode is disabled, enable it.
$ nvidia-smi -i [gpu-ids] -mig 1
gpu-ids
A comma-separated list of GPU indexes, PCI bus IDs or UUIDs that specifies the
GPUs on which you want to enable MIG mode. If gpu-ids is omitted, MIG mode is
enabled on all GPUs on the system.
This example enables MIG mode on GPU 0.
$ nvidia-smi -i 0 -mig 1
Enabled MIG Mode for GPU 00000000:36:00.0
All done.
Note: If the GPU is being used by another process, this command fails and displays a
warning message that MIG mode for the GPU is in the pending enable state. In this
situation, stop all processes that are using the GPU and retry the command.
1. If necessary, open a command shell as the root user on your hypervisor host machine.
2. List the GPU instance profiles that are available on your GPU.
You will need to specify the profiles by their IDs, not their names, when you create
them.
$ nvidia-smi mig -lgip
+--------------------------------------------------------------------------+
| GPU instance profiles: |
| GPU Name ID Instances Memory P2P SM DEC ENC |
| Free/Total GiB CE JPEG OFA |
|==========================================================================|
| 0 MIG 1g.5gb 19 7/7 4.95 No 14 0 0 |
| 1 0 0 |
+--------------------------------------------------------------------------+
| 0 MIG 2g.10gb 14 3/3 9.90 No 28 1 0 |
| 2 0 0 |
+--------------------------------------------------------------------------+
| 0 MIG 3g.20gb 9 2/2 19.79 No 42 2 0 |
| 3 0 0 |
+--------------------------------------------------------------------------+
| 0 MIG 4g.20gb 5 1/1 19.79 No 56 2 0 |
| 4 0 0 |
+--------------------------------------------------------------------------+
| 0 MIG 7g.40gb 0 1/1 39.59 No 98 5 0 |
| 7 1 1 |
+--------------------------------------------------------------------------+
3. Create the GPU instances that correspond to the vGPU types of the MIG-backed
vGPUs that you will create.
$ nvidia-smi mig -cgi gpu-instance-profile-ids
gpu-instance-profile-ids
A comma-separated list of GPU instance profile IDs that specifies the GPU
instances that you want to create.
This example creates two GPU instances of type 2g.10gb, which has profile ID 14.
$ nvidia-smi mig -cgi 14,14
Successfully created GPU instance ID 5 on GPU 2 using profile MIG 2g.10gb (ID
14)
Successfully created GPU instance ID 3 on GPU 2 using profile MIG 2g.10gb (ID
14)
Note: If you are using VMware vSphere, omit this task. After the VM is booted and guest
driver is installed, one compute instance is automatically created in the VM.
1. If necessary, open a command shell as the root user on your hypervisor host machine.
2. List the available GPU instances.
$ nvidia-smi mig -lgi
+----------------------------------------------------+
| GPU instances: |
| GPU Name Profile Instance Placement |
| ID ID Start:Size |
|====================================================|
| 2 MIG 2g.10gb 14 3 0:2 |
+----------------------------------------------------+
| 2 MIG 2g.10gb 14 5 4:2 |
+----------------------------------------------------+
3. Create the compute instances that you need within each GPU instance.
$ nvidia-smi mig -cci -gi gpu-instance-ids
gpu-instance-ids
A comma-separated list of GPU instance IDs that specifies the GPU instances
within which you want to create the compute instances.
CAUTION: To avoid an inconsistent state between a guest VM and the hypervisor host,
do not create compute instances from the hypervisor on a GPU instance on which an
active guest VM is running. Instead, create the compute instances from within the
guest VM as explained in Modifying a MIG-Backed vGPU's Configuration.
| 2 5 0 1 | 0MiB / 9984MiB | 28 0 | 2 0 1 0 0 |
| | 0MiB / 16383MiB | | |
+------------------+----------------------+-----------+-----------------------+
+-----------------------------------------------------------------------------+
| Processes: |
| GPU GI CI PID Type Process name GPU Memory |
| ID ID Usage |
|=============================================================================|
Note: Additional compute instances that have been created in a VM are destroyed
when the VM is shut down or rebooted. After the shutdown or reboot, only one
compute instance remains in the VM. This compute instance is created automatically
after the NVIDIA vGPU software graphics driver is installed.
1. Open a command shell as the root user on your hypervisor host machine.
You can use secure shell (SSH) for this purpose.
2. Determine whether MIG mode is disabled.
Use the nvidia-smi command for this purpose. By default, MIG mode is disabled, but
might have previously been enabled.
This example shows that MIG mode is enabled on GPU 0.
Note: In the output from output from nvidia-smi, the NVIDIA A100 HGX 40GB GPU is
referred to as A100-SXM4-40GB.
$ nvidia-smi -i 0
+-----------------------------------------------------------------------------+
| NVIDIA-SMI 470.223.02 Driver Version: 470.223.02 CUDA Version: 11.4 |
|-------------------------------+----------------------+----------------------+
| GPU Name Persistence-M| Bus-Id Disp.A | Volatile Uncorr. ECC |
| Fan Temp Perf Pwr:Usage/Cap| Memory-Usage | GPU-Util Compute M. |
| | | MIG M. |
|===============================+======================+======================|
| 0 A100-SXM4-40GB Off | 00000000:36:00.0 Off | 0 |
| N/A 29C P0 62W / 400W | 0MiB / 40537MiB | 6% Default |
| | | Enabled |
+-------------------------------+----------------------+----------------------+
3. If MIG mode is enabled, disable it.
$ nvidia-smi -i [gpu-ids] -mig 0
gpu-ids
A comma-separated list of GPU indexes, PCI bus IDs or UUIDs that specifies the
GPUs on which you want to disable MIG mode. If gpu-ids is omitted, MIG mode is
disabled on all GPUs on the system.
This example disables MIG mode on GPU 0.
$ sudo nvidia-smi -i 0 -mig 0
Disabled MIG Mode for GPU 00000000:36:00.0
All done.
4. Confirm that MIG mode was disabled.
Use the nvidia-smi command for this purpose.
This example shows that MIG mode is disabled on GPU 0.
$ nvidia-smi -i 0
+-----------------------------------------------------------------------------+
| NVIDIA-SMI 470.223.02 Driver Version: 470.223.02 CUDA Version: 11.4 |
|-------------------------------+----------------------+----------------------+
| GPU Name Persistence-M| Bus-Id Disp.A | Volatile Uncorr. ECC |
| Fan Temp Perf Pwr:Usage/Cap| Memory-Usage | GPU-Util Compute M. |
| | | MIG M. |
|===============================+======================+======================|
| 0 A100-SXM4-40GB Off | 00000000:36:00.0 Off | 0 |
| N/A 29C P0 62W / 400W | 0MiB / 40537MiB | 6% Default |
| | | Disabled |
+-------------------------------+----------------------+----------------------+
‣ ECC memory is exposed as a feature on all supported vGPUs on the physical GPU.
‣ In VMs that support ECC memory, ECC memory is enabled, with the option to disable
ECC in the VM.
‣ ECC memory can be enabled or disabled for individual VMs. Enabling or disabling ECC
memory in a VM does not affect the amount of frame buffer that is usable by vGPUs.
GPUs based on the Pascal GPU architecture and later GPU architectures support ECC
memory with NVIDIA vGPU. To determine whether ECC memory is enabled for a GPU, run
nvidia-smi -q for the GPU.
Tesla M60 and M6 GPUs support ECC memory when used without GPU virtualization, but
NVIDIA vGPU does not support ECC memory with these GPUs. In graphics mode, these
GPUs are supplied with ECC memory disabled by default.
Some hypervisor software versions do not support ECC memory with NVIDIA vGPU.
If you are using a hypervisor software version or GPU that does not support ECC memory
with NVIDIA vGPU and ECC memory is enabled, NVIDIA vGPU fails to start. In this
situation, you must ensure that ECC memory is disabled on all GPUs if you are using
NVIDIA vGPU.
‣ For a physical GPU, perform this task from the hypervisor host.
‣ For a vGPU, perform this task from the VM to which the vGPU is assigned.
Note: ECC memory must be enabled on the physical GPU on which the vGPUs reside.
Before you begin, ensure that NVIDIA Virtual GPU Manager is installed on your hypervisor.
If you are changing ECC memory settings for a vGPU, also ensure that the NVIDIA vGPU
software graphics driver is installed in the VM to which the vGPU is assigned.
1. Use nvidia-smi to list the status of all physical GPUs or vGPUs, and check for ECC
noted as enabled.
# nvidia-smi -q
==============NVSMI LOG==============
Attached GPUs : 1
GPU 0000:02:00.0
[...]
Ecc Mode
Current : Enabled
Pending : Enabled
[...]
2. Change the ECC status to off for each GPU for which ECC is enabled.
‣ If you want to change the ECC status to off for all GPUs on your host machine or
vGPUs assigned to the VM, run this command:
# nvidia-smi -e 0
‣ If you want to change the ECC status to off for a specific GPU or vGPU, run this
command:
# nvidia-smi -i id -e 0
==============NVSMI LOG==============
Attached GPUs : 1
GPU 0000:02:00.0
[...]
Ecc Mode
Current : Disabled
Pending : Disabled
[...]
If you later need to enable ECC on your GPUs or vGPUs, follow the instructions in Enabling
ECC Memory.
‣ For a physical GPU, perform this task from the hypervisor host.
‣ For a vGPU, perform this task from the VM to which the vGPU is assigned.
Note: ECC memory must be enabled on the physical GPU on which the vGPUs reside.
Before you begin, ensure that NVIDIA Virtual GPU Manager is installed on your hypervisor.
If you are changing ECC memory settings for a vGPU, also ensure that the NVIDIA vGPU
software graphics driver is installed in the VM to which the vGPU is assigned.
1. Use nvidia-smi to list the status of all physical GPUs or vGPUs, and check for ECC
noted as disabled.
# nvidia-smi -q
==============NVSMI LOG==============
Attached GPUs : 1
GPU 0000:02:00.0
[...]
Ecc Mode
Current : Disabled
Pending : Disabled
[...]
2. Change the ECC status to on for each GPU or vGPU for which ECC is enabled.
‣ If you want to change the ECC status to on for all GPUs on your host machine or
vGPUs assigned to the VM, run this command:
# nvidia-smi -e 1
‣ If you want to change the ECC status to on for a specific GPU or vGPU, run this
command:
# nvidia-smi -i id -e 1
==============NVSMI LOG==============
Attached GPUs : 1
GPU 0000:02:00.0
[...]
Ecc Mode
Current : Enabled
Pending : Enabled
[...]
If you later need to disable ECC on your GPUs or vGPUs, follow the instructions in
Disabling ECC Memory.
GPU pass-through is used to directly assign an entire physical GPU to one VM, bypassing
the NVIDIA Virtual GPU Manager. In this mode of operation, the GPU is accessed
exclusively by the NVIDIA driver running in the VM to which it is assigned; the GPU is not
shared among VMs.
In pass-through mode, GPUs based on NVIDIA GPU architectures after the Maxwell
architecture support error-correcting code (ECC).
GPU pass-through can be used in a server platform alongside NVIDIA vGPU, with some
restrictions:
‣ A physical GPU can host NVIDIA vGPUs, or can be used for pass-through, but cannot
do both at the same time. Some hypervisors, for example VMware vSphere ESXi,
require a host reboot to change a GPU from pass-through mode to vGPU mode.
‣ A single VM cannot be configured for both vGPU and GPU pass-through at the same
time.
‣ The performance of a physical GPU passed through to a VM can be monitored only
from within the VM itself. Such a GPU cannot be monitored by tools that operate
through the hypervisor, such as XenCenter or nvidia-smi (see Monitoring GPU
Performance).
‣ The following BIOS settings must be enabled on your server platform:
‣ VT-D/IOMMU
‣ SR-IOV in Advanced Options
‣ All GPUs directly connected to each other through NVLink must be assigned to the
same VM.
You can assign multiple physical GPUs to one VM. The maximum number of physical
GPUs that you can assign to a VM depends on the maximum number of PCIe pass-
through devices per VM that your chosen hypervisor can support. For more information,
refer to the documentation for your hypervisor, for example:
Note: If you intend to configure all GPUs in your server platform for pass-through, you do
not need to install the NVIDIA Virtual GPU Manager.
Note: You cannot use more than four displays even if the combined resolution of the
displays is less than the number of available pixels from the GPU. For example, you cannot
use five 4096×2160 displays with a GPU based on the NVIDIA Pascal architecture even
though the combined resolution of the displays (44236800) is less than the number of
available pixels from the GPU (66355200).
After configuring a Citrix Hypervisor VM for GPU pass through, install the NVIDIA
graphics driver in the guest OS on the VM as explained in Installing the NVIDIA vGPU
Software Graphics Driver.
[root@xenserver ~]#
After configuring a Citrix Hypervisor VM for GPU pass through, install the NVIDIA
graphics driver in the guest OS on the VM as explained in Installing the NVIDIA vGPU
Software Graphics Driver.
2. In the virt-manager main window, select the VM that you want to configure for pass-
through.
3. From the Edit menu, choose Virtual Machine Details.
4. In the virtual machine hardware information window that opens, click Add Hardware.
5. In the Add New Virtual Hardware dialog box that opens, in the hardware list on the
left, select PCI Host Device.
6. From the Host Device list that appears, select the GPU that you want to assign to the
VM and click Finish.
If you want to remove a GPU from the VM to which it is assigned, in the virtual machine
hardware information window, select the GPU and click Remove.
After configuring the VM for GPU pass through, install the NVIDIA graphics driver in the
guest OS on the VM as explained in Installing the NVIDIA vGPU Software Graphics Driver.
The NVIDIA GPUs listed in this example have the PCI device BDFs 85:00.0 and
86:00.0.
# lspci | grep NVIDIA
85:00.0 VGA compatible controller: NVIDIA Corporation GM204GL [Tesla M60] (rev
a1)
86:00.0 VGA compatible controller: NVIDIA Corporation GM204GL [Tesla M60] (rev
a1)
3. Obtain the full identifier of the GPU from its PCI device BDF.
# virsh nodedev-list --cap pci| grep transformed-bdf
transformed-bdf
The PCI device BDF of the GPU with the colon and the period replaced with
underscores, for example, 85_00_0.
This example obtains the full identifier of the GPU with the PCI device BDF 85:00.0.
# virsh nodedev-list --cap pci| grep 85_00_0
pci_0000_85_00_0
4. Obtain the domain, bus, slot, and function of the GPU.
virsh nodedev-dumpxml full-identifier| egrep 'domain|bus|slot|function'
full-identifier
The full identifier of the GPU that you obtained in the previous step, for example,
pci_0000_85_00_0.
This example obtains the domain, bus, slot, and function of the GPU with the PCI
device BDF 85:00.0.
# virsh nodedev-dumpxml pci_0000_85_00_0| egrep 'domain|bus|slot|function'
<domain>0x0000</domain>
<bus>0x85</bus>
<slot>0x00</slot>
<function>0x0</function>
<address domain='0x0000' bus='0x85' slot='0x00' function='0x0'/>
5. In virsh, open for editing the XML file of the VM that you want to assign the GPU to.
# virsh edit vm-name
vm-name
The name of the VM to that you want to assign the GPU to.
6. Add a device entry in the form of an address element inside the source element to
assign the GPU to the guest VM.
You can optionally add a second address element after the source element to set a
fixed PCI device BDF for the GPU in the guest operating system.
<hostdev mode='subsystem' type='pci' managed='yes'>
<source>
<address domain='domain' bus='bus' slot='slot' function='function'/>
</source>
<address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0'/>
</hostdev>
domain
bus
slot
function
The domain, bus, slot, and function of the GPU, which you obtained in the previous
step.
This example adds a device entry for the GPU with the PCI device BDF 85:00.0 and
fixes the BDF for the GPU in the guest operating system.
<hostdev mode='subsystem' type='pci' managed='yes'>
<source>
<address domain='0x0000' bus='0x85' slot='0x00' function='0x0'/>
</source>
<address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0'/>
</hostdev>
7. Start the VM that you assigned the GPU to.
# virsh start vm-name
vm-name
The name of the VM that you assigned the GPU to.
After configuring the VM for GPU pass through, install the NVIDIA graphics driver in the
guest OS on the VM as explained in Installing the NVIDIA vGPU Software Graphics Driver.
The NVIDIA GPUs listed in this example have the PCI device BDFs 85:00.0 and
86:00.0.
# lspci | grep NVIDIA
85:00.0 VGA compatible controller: NVIDIA Corporation GM204GL [Tesla M60] (rev
a1)
86:00.0 VGA compatible controller: NVIDIA Corporation GM204GL [Tesla M60] (rev
a1)
2. Add the following option to the QEMU command line:
-device vfio-pci,host=bdf
bdf
The PCI device BDF of the GPU that you want to assign in pass-through mode to a
VM, for example, 85:00.0.
This example assigns the GPU with the PCI device BDF 85:00.0 in pass-through mode
to a VM.
-device vfio-pci,host=85:00.0
After configuring the VM for GPU pass through, install the NVIDIA graphics driver in the
guest OS on the VM as explained in Installing the NVIDIA vGPU Software Graphics Driver.
1. If you are using a GPU that supports SR-IOV, such as a GPU based on the NVIDIA
Ampere architecture, disable the virtual function for the GPU in the sysfs file system.
Note: Before performing this step, ensure that the GPU is not being used by any other
processes, such as CUDA applications, monitoring applications, or the nvidia-smi
command.
Use the custom script sriov-manage provided by NVIDIA vGPU software for this
purpose.
# /usr/lib/nvidia/sriov-manage -d domain:bus:slot.function
domain
bus
slot
function
The domain, bus, slot, and function of the GPU, without the 0x prefix.
This example disables the virtual function for the GPU with the domain 00, bus 06, slot
0000, and function 0.
# /usr/lib/nvidia/sriov-manage -d 00:06:0000.0
2. Determine the kernel module to which the GPU is bound by running the lspci
command with the -k option on the NVIDIA GPUs on your host.
# lspci -d 10de: -k
The Kernel driver in use: field indicates the kernel module to which the GPU is
bound.
The following example shows that the NVIDIA Tesla M60 GPU with BDF 06:00.0 is
bound to the nvidia kernel module and is being used for vGPU.
06:00.0 VGA compatible controller: NVIDIA Corporation GM204GL [Tesla M60] (rev
a1)
Subsystem: NVIDIA Corporation Device 115e
Kernel driver in use: nvidia
3. To ensure that no clients are using the GPU, acquire the unbind lock of the GPU.
a). Ensure that no VM is running to which a vGPU on the physical GPU is assigned and
that no process running on the host is using that GPU.
Processes on the host that use the GPU include the nvidia-smi command and all
processes based on the NVIDIA Management Library (NVML).
b). Change to the directory in the proc file system that represents the GPU.
# cd /proc/driver/nvidia/gpus/domain\:bus\:slot.function
domain
bus
slot
function
The domain, bus, slot, and function of the GPU, without a 0x prefix.
This example changes to the directory in the proc file system that represents the
GPU with the domain 0000 and PCI device BDF 06:00.0.
# cd /proc/driver/nvidia/gpus/0000\:06\:00.0
c). Write the value 1 to the unbindLock file in this directory.
# echo 1 > unbindLock
d). Confirm that the unbindLock file now contains the value 1.
# cat unbindLock
1
If the unbindLock file contains the value 0, the unbind lock could not be acquired
because a process or client is using the GPU.
4. Unbind the GPU from nvidia kernel module.
a). Change to the sysfs directory that represents the nvidia kernel module.
# cd /sys/bus/pci/drivers/nvidia
b). Write the domain, bus, slot, and function of the GPU to the unbind file in this
directory.
# echo domain:bus:slot.function > unbind
domain
bus
slot
function
The domain, bus, slot, and function of the GPU, without a 0x prefix.
This example writes the domain, bus, slot, and function of the GPU with the
domain 0000 and PCI device BDF 06:00.0.
# echo 0000:06:00.0 > unbind
5. Bind the GPU to the vfio-pci kernel module.
a). Change to the sysfs directory that contains the PCI device information for the
physical GPU.
# cd /sys/bus/pci/devices/domain\:bus\:slot.function
domain
bus
slot
function
The domain, bus, slot, and function of the GPU, without a 0x prefix.
This example changes to the sysfs directory that contains the PCI device
information for the GPU with the domain 0000 and PCI device BDF 06:00.0.
# cd /sys/bus/pci/devices/0000\:06\:00.0
b). Write the kernel module name vfio-pci to the driver_override file in this
directory.
# echo vfio-pci > driver_override
c). Change to the sysfs directory that represents the nvidia kernel module.
# cd /sys/bus/pci/drivers/vfio-pci
d). Write the domain, bus, slot, and function of the GPU to the bind file in this
directory.
# echo domain:bus:slot.function > bind
domain
bus
slot
function
The domain, bus, slot, and function of the GPU, without a 0x prefix.
This example writes the domain, bus, slot, and function of the GPU with the
domain 0000 and PCI device BDF 06:00.0.
# echo 0000:06:00.0 > bind
e). Change back to the sysfs directory that contains the PCI device information for
the physical GPU.
# cd /sys/bus/pci/devices/domain\:bus\:slot.function
f). Clear the content of the driver_override file in this directory.
# echo > driver_override
You can now configure the GPU for use in pass-through mode as explained in Using GPU
Pass-Through on Red Hat Enterprise Linux KVM or Ubuntu.
‣ Windows Server with Desktop Experience and the Hyper-V role are installed and
configured on your server platform, and a VM is created.
For instructions, refer to the following articles on the Microsoft technical
documentation site:
b). In the Properties window that opens, click the Details tab and in the Properties
drop-down list, select Location paths.
An example location path is as follows:
PCIROOT(80)#PCI(0200)#PCI(0000)#PCI(1000)#PCI(0000)
2. If you are using an actively cooled NVIDIA Quadro graphics card, obtain the location
path of the audio device on the graphics card and disable the device.
a). In the device manager, from the View menu, choose Devices by connection.
b). Navigate to ACPI x64-based PC > Microsoft ACPI-Compliant System > PCI
Express Root Complex > PCI-to-PCI Bridge .
c). Context-click High Definition Audio Controller and from the menu that pops up,
choose Properties.
d). In the Properties window that opens, click the Details tab and in the Properties
drop-down list, select Location paths.
e). Context-click High Definition Audio Controller again and from the menu that pops
up, choose Disable device.
3. Dismount the GPU and, if present, the audio device from host to make them
unavailable to the host so that they can be used solely by the VM.
For each device that you are dismounting, type the following command:
Dismount-VMHostAssignableDevice -LocationPath gpu-device-location -force
gpu-device-location
The location path of the GPU or the audio device that you obtained previously.
This example dismounts the GPU at the location path
PCIROOT(80)#PCI(0200)#PCI(0000)#PCI(1000)#PCI(0000).
Dismount-VMHostAssignableDevice -LocationPath
"PCIROOT(80)#PCI(0200)#PCI(0000)#PCI(1000)#PCI(0000)" -force
4. Assign the GPU and, if present, the audio device that you dismounted in the previous
step to the VM.
For each device that you are assigning, type the following command:
Add-VMAssignableDevice -LocationPath gpu-device-location -VMName vm-name
gpu-device-location
The location path of the GPU or the audio device that you dismounted in the
previous step.
vm-name
The name of the VM to which you are attaching the GPU or the audio device.
Note: You can assign a pass-through GPU and, if present, its audio device to only one
virtual machine at a time.
After assigning a GPU to a VM, install the NVIDIA graphics driver in the guest OS on the
VM as explained in Installing the NVIDIA vGPU Software Graphics Driver.
1. List the GPUs and, if present, the audio devices that are currently assigned to the
virtual machine (VM).
Get-VMAssignableDevice -VMName vm-name
vm-name
The name of the VM whose assigned GPUs and audio devices you want to list.
2. Shut down the VM to which the GPU and any audio devices are assigned.
3. Remove the GPU and, if present, the audio device from the VM to which they are
assigned.
For each device that you are removing, type the following command:
Remove-VMAssignableDevice –LocationPath gpu-device-location -VMName vm-name
gpu-device-location
The location path of the GPU or the audio device that you are removing, which you
obtained previously.
vm-name
The name of the VM from which you are removing the GPU or the audio device.
This example removes the GPU at the location path
PCIROOT(80)#PCI(0200)#PCI(0000)#PCI(1000)#PCI(0000) from the VM VM1.
Remove-VMAssignableDevice –LocationPath
"PCIROOT(80)#PCI(0200)#PCI(0000)#PCI(1000)#PCI(0000)" -VMName VM1
After the GPU and, if present, its audio device are removed from the VM, they are
unavailable to the host operating system (OS) until you remount them on the host OS.
4. Remount the GPU and, if present, its audio device on the host OS.
For each device that you are remounting, type the following command:
Mount-VMHostAssignableDevice –LocationPath gpu-device-location
gpu-device-location
The location path of the GPU or the audio device that you are remounting, which
you specified in the previous step to remove the GPU or the audio device from the
VM.
This example remounts the GPU at the location path
PCIROOT(80)#PCI(0200)#PCI(0000)#PCI(1000)#PCI(0000) on the host OS.
Mount-VMHostAssignableDevice -LocationPath
"PCIROOT(80)#PCI(0200)#PCI(0000)#PCI(1000)#PCI(0000)"
The host OS should now be able to use the GPU and, if present, its audio device.
‣ The VM and the ESXi host are configured as explained in Preparing for vDGA
Capabilities in the VMware Horizon documentation.
‣ The VM is powered off.
1. Open the vCenter Web UI.
2. In the vCenter Web UI, right-click the ESXi host and choose Configure.
3. From the Hardware menu, choose PCI Devices.
4. On the PCI Devices page that opens, click ALL PCI DEVICES and in the table of
devices, select the GPU.
Note: When selecting the GPU to pass through, you must select only the physical
device. To list only NVIDIA physical devices, set the filter on the Vendor Name field to
NVIDIA and filter out any virtual function devices of the GPU by setting the filter on
the ID field to 00.0.
8. From the New Device menu, choose PCI Device and click Add.
9. On the page that opens, from the New Device drop-down list, select the GPU.
10.Click Reserve all memory and click OK.
11.Start the VM.
For more information about vDGA, see the following topics in the VMware Horizon
documentation:
The process for installing the NVIDIA vGPU software graphics driver depends on the OS
that you are using. However, for any OS, the process for installing the driver is the same
in a VM configured with vGPU, in a VM that is running pass-through GPU, or on a physical
host in a bare-metal deployment.
After you install the NVIDIA vGPU software graphics driver, you can license any NVIDIA
vGPU software licensed products that you are using.
1. Copy the NVIDIA Windows driver package to the guest VM or physical host where you
are installing the driver.
2. Execute the package to unpack and run the driver installer.
Installation in a VM: After you install the NVIDIA vGPU software graphics driver, you can
license any NVIDIA vGPU software licensed products that you are using. For instructions,
refer to Virtual GPU Client Licensing User Guide.
Installation on bare metal: After you install the NVIDIA vGPU software graphics driver,
complete the bare-metal deployment as explained in Bare-Metal Deployment.
‣ Compiler toolchain
‣ Kernel headers
Before installing the NVIDIA vGPU software graphics driver, ensure that the following
prerequisites are met:
1. Copy the NVIDIA vGPU software Linux driver package, for example NVIDIA-
Linux_x86_64-470.223.02-grid.run, to the guest VM or physical host where you are
installing the driver.
2. Before attempting to run the driver installer, exit the X server and terminate all
OpenGL applications.
‣ On Red Hat Enterprise Linux and CentOS systems, exit the X server by
transitioning to runlevel 3:
[nvidia@localhost ~]$ sudo init 3
‣ On Ubuntu platforms, do the following:
a). Switch to a console login prompt.
Installation in a VM: After you install the NVIDIA vGPU software graphics driver, you can
license any NVIDIA vGPU software licensed products that you are using. For instructions,
refer to Virtual GPU Client Licensing User Guide.
Installation on bare metal: After you install the NVIDIA vGPU software graphics driver,
complete the bare-metal deployment as explained in Bare-Metal Deployment.
Note: If you are using SUSE Linux Enterprise Server, you can skip this task because the
Nouveau driver is not present in SUSE Linux Enterprise Server.
Run the following command and if the command prints any output, the Nouveau driver is
present and must be disabled.
$ lsmod | grep nouveau
1. In a plain text editor, edit the file /etc/gdm/custom.conf and remove the comment
from the option WaylandEnable=false.
2. Save your changes to /etc/gdm/custom.conf.
3. Reboot the host or guest VM.
NVIDIA vGPU is a licensed product. When booted on a supported GPU, a vGPU initially
operates at full capability but its performance is degraded over time if the VM fails to
obtain a license. If the performance of a vGPU has been degraded, the full capability
of the vGPU is restored when a license is acquired. For information about how the
performance of an unlicensed vGPU is degraded, see Virtual GPU Client Licensing User
Guide.
After you license NVIDIA vGPU, the VM that is set up to use NVIDIA vGPU is capable of
running the full range of DirectX and OpenGL graphics applications.
If licensing is configured, the virtual machine (VM) obtains a license from the license
server when a vGPU is booted on these GPUs. The VM retains the license until it is shut
down. It then releases the license back to the license server. Licensing settings persist
across reboots and need only be modified if the license server address changes, or the
VM is switched to running GPU pass through.
How to license an NVIDIA vGPU depends on whether your licenses are served from
NVIDIA License System or the legacy NVIDIA vGPU software license server.
Note: For complete information about configuring and using NVIDIA vGPU software
licensed features, including vGPU, refer to Virtual GPU Client Licensing User Guide.
‣ The client configuration token that you want to deploy on the client has been created
from the NVIDIA Licensing Portal or the DLS as explained in NVIDIA License System
User Guide.
‣ Ports 443 and 80 in your firewall or proxy must be open to allow HTTPS traffic
between a service instance and its the licensed clients. These ports must be open for
both CLS instances and DLS instances.
Note: For DLS releases before DLS 1.1, ports 8081 and 8082 were also required to be
open to allow HTTPS traffic between a DLS instance and its licensed clients. Although
these ports are no longer required, they remain supported for backward compatibility.
The graphics driver creates a default location in which to store the client configuration
token on the client.
The process for configuring a licensed client is the same for CLS and DLS instances but
depends on the OS that is running on the client.
The NVIDIA service on the client should now automatically obtain a license from the CLS
or DLS instance.
Note: You can create the /etc/nvidia/gridd.conf file by copying the supplied
template file /etc/nvidia/gridd.conf.template.
Note: You can also perform this step from NVIDIA X Server Settings. Before using
NVIDIA X Server Settings to perform this step, ensure that this option has been
enabled as explained in Virtual GPU Client Licensing User Guide.
This example shows how to configure a licensed Linux client for NVIDIA RTX Virtual
Workstation.
# /etc/nvidia/gridd.conf.template - Configuration file for NVIDIA Grid Daemon
…
# Description: Set Feature to be enabled
# Data type: integer
# Possible values:
# 0 => for unlicensed state
# 1 => for NVIDIA vGPU
# 2 => for NVIDIA RTX Virtual Workstation
# 4 => for NVIDIA Virtual Compute Server
FeatureType=2
...
3. Copy the client configuration token to the /etc/nvidia/ClientConfigToken
directory.
4. Ensure that the file access modes of the client configuration token allow the owner to
read, write, and execute the token, and the group and others only to read the token.
a). Determine the current file access modes of the client configuration token.
# ls -l client-configuration-token-directory
b). If necessary, change the mode of the client configuration token to 744.
# chmod 744 client-configuration-token-directory/client_configuration_token_*.tok
client-configuration-token-directory
The directory to which you copied the client configuration token in the previous
step.
5. Save your changes to the /etc/nvidia/gridd.conf file and close the file.
6. Restart the nvidia-gridd service.
The NVIDIA service on the client should now automatically obtain a license from the CLS
or DLS instance.
Attached GPUs : 1
GPU 00000000:00:08.0
Product Name : Tesla T4
Product Brand : Grid
Display Mode : Enabled
Display Active : Disabled
Persistence Mode : N/A
Accounting Mode : Disabled
Accounting Mode Buffer Size : 4000
Driver Model
Current : WDDM
Pending : WDDM
Serial Number : 0334018000638
GPU UUID : GPU-ba2310b6-95d1-802b-f96f-5865410fe517
Minor Number : N/A
VBIOS Version : 90.04.21.00.01
MultiGPU Board : No
Board ID : 0x8
GPU Part Number : 699-2G183-0200-100
Inforom Version
Image Version : G183.0200.00.02
OEM Object : 1.1
ECC Object : 5.0
Power Management Object : N/A
GPU Operation Mode
Current : N/A
Pending : N/A
GPU Virtualization Mode
Virtualization mode : Pass-Through
vGPU Software Licensed Product
Product Name : NVIDIA Virtual Compute Server
License Status : Licensed (Expiry: 2021-11-13 18:29:59 GMT)
…
…
‣ Right-click on the Windows desktop and select NVIDIA Control Panel from the
menu.
‣ Open Windows Control Panel and double-click the NVIDIA Control Panel icon.
2. In NVIDIA Control Panel, select the Manage License task in the Licensing section of
the navigation pane.
Note: If the Licensing section and Manage License task are not displayed in NVIDIA
Control Panel, the system has been configured to hide licensing controls in NVIDIA
Control Panel. For information about registry settings, refer to Virtual GPU Client
Licensing User Guide.
The Manage License task pane shows that NVIDIA vGPU is currently unlicensed.
3. In the Primary License Server field, enter the address of your primary NVIDIA vGPU
software License Server.
The address can be a fully-qualified domain name such as
gridlicense1.example.com, or an IP address such as 10.31.20.45.
If you have only one license server configured, enter its address in this field.
4. Leave the Port Number field under the Primary License Server field unset.
The port defaults to 7070, which is the default port number used by NVIDIA vGPU
software License Server.
5. In the Secondary License Server field, enter the address of your secondary NVIDIA
vGPU software License Server.
If you have only one license server configured, leave this field unset.
The address can be a fully-qualified domain name such as
gridlicense2.example.com, or an IP address such as 10.31.20.46.
6. Leave the Port Number field under the Secondary License Server field unset.
The port defaults to 7070, which is the default port number used by NVIDIA vGPU
software License Server.
7. Click Apply to assign the settings.
The system requests the appropriate license for the current vGPU from the
configured license server.
The vGPU within the VM should now operate at full capability without any performance
degradation over time for as long as the vGPU is licensed.
If the system fails to obtain a license, see Virtual GPU Client Licensing User Guide for
guidance on troubleshooting.
Note: Do not enable the Manage License option with Red Hat Enterprise Linux 6.8 and 6.9
or CentOS 6.8 and 6.9. To prevent a segmentation fault in DBus code from causing the
nvidia-gridd service from exiting, the GUI for licensing must be disabled with these OS
versions.
1. Start NVIDIA X Server Settings by using the method for launching applications
provided by your Linux distribution.
For example, on Ubuntu Desktop, open the Dash, search for NVIDIA X Server
Settings, and click the NVIDIA X Server Settings icon.
2. In the NVIDIA X Server Settings window that opens, click Manage GRID License.
The License Edition section of the NVIDIA X Server Settings window shows that
NVIDIA vGPU is currently unlicensed.
3. In the Primary Server field, enter the address of your primary NVIDIA vGPU software
License Server.
The address can be a fully-qualified domain name such as
gridlicense1.example.com, or an IP address such as 10.31.20.45.
If you have only one license server configured, enter its address in this field.
4. Leave the Port Number field under the Primary Server field unset.
The port defaults to 7070, which is the default port number used by NVIDIA vGPU
software License Server.
5. In the Secondary Server field, enter the address of your secondary NVIDIA vGPU
software License Server.
If you have only one license server configured, leave this field unset.
The address can be a fully-qualified domain name such as
gridlicense2.example.com, or an IP address such as 10.31.20.46.
6. Leave the Port Number field under the Secondary Server field unset.
The port defaults to 7070, which is the default port number used by NVIDIA vGPU
software License Server.
7. Click Apply to assign the settings.
The system requests the appropriate license for the current vGPU from the
configured license server.
The vGPU within the VM should now operate at full capability without any performance
degradation over time for as long as the vGPU is licensed.
If the system fails to obtain a license, refer to Virtual GPU Client Licensing User Guide for
guidance on troubleshooting.
You can modify a VM's NVIDIA vGPU configuration by removing the NVIDIA vGPU
configuration from a VM or by modifying GPU allocation policy.
Note: The VM must be in the powered-off state in order for its vGPU configuration to be
modified or removed.
2. Click OK.
1. Select Edit settings after right-clicking on the VM in the vCenter Web UI.
2. Select the Virtual Hardware tab.
3. Mouse over the PCI Device entry showing NVIDIA GRID vGPU and click on the (X) icon
to mark the device for removal.
4. Click OK to remove the device and update the VM settings.
[root@xenserver ~]#
‣ Supported versions earlier than 6.5: Add the following parameter to /etc/vmware/
config:
vGPU.consolidation = true
‣ Version 6.5: Use the vSphere Web Client.
Before using the vSphere Web Client to change the allocation scheme, ensure that the
ESXi host is running and that all VMs on the host are powered off.
5. In the Edit Host Graphics Settings dialog box that opens, select these options and
click OK.
a). If not already selected, select Shared Direct.
b). Select Group VMs on GPU until full.
After you click OK, the default graphics type changes to Shared Direct and the
allocation scheme for vGPU-enabled VMs is breadth-first.
Note: vGPU migration is disabled for a VM for which any of the following NVIDIA CUDA
Toolkit features is enabled:
‣ Unified memory
‣ Debuggers
‣ Profilers
How to migrate a VM configured with vGPU depends on the hypervisor that you are using.
After migration, the vGPU type of the vGPU remains unchanged.
The time required for migration depends on the amount of frame buffer that the vGPU
has. Migration for a vGPU with a large amount of frame buffer is slower than for a vGPU
with a small amount of frame buffer.
1. In Citrix XenCenter, context-click the VM and from the menu that opens, choose
Migrate.
2. From the list of available hosts, select the destination host to which you want to
migrate the VM.
The destination host must have a physical GPU of the same type as the GPU where
the vGPU currently resides. Furthermore, the physical GPU must be capable of hosting
the vGPU. If these requirements are not met, no available hosts are listed.
‣ Your hosts are correctly configured for VMware vMotion. See Host Configuration for
vMotion in the VMware documentation.
‣ The prerequisites listed for all supported hypervisors in Migrating a VM Configured
with vGPU are met.
‣ NVIDIA vGPU migration is configured. See Configuring VMware vMotion with vGPU for
VMware vSphere.
1. Context-click the VM and from the menu that opens, choose Migrate.
2. For the type of migration, select Change compute resource only and click Next.
If you select Change both compute resource and storage, the time required for the
migration increases.
3. Select the destination host and click Next.
The destination host must have a physical GPU of the same type as the GPU where
the vGPU currently resides. Furthermore, the physical GPU must be capable of hosting
the vGPU. If these requirements are not met, no available hosts are listed.
4. Select the destination network and click Next.
5. Select the migration priority level and click Next.
6. Review your selections and click Finish.
For more information, see the following topics in the VMware documentation:
If you see this error, configure NVIDIA vGPU migration as explained in Configuring
VMware vMotion with vGPU for VMware vSphere.
If your version of VMware vSpehere ESXi does not support vMotion for VMs configured
with NVIDIA vGPU, any attempt to migrate a VM with an NVIDIA vGPU fails and a window
containing the following error message is displayed:
Compatibility Issues
...
A required migration feature is not supported on the "Source" host 'host-name'.
For details about which VMware vSphere versions, NVIDIA GPUs, and guest OS releases
support suspend and resume, see Virtual GPU Software for VMware vSphere Release Notes.
‣ To suspend a VM, context-click the VM that you want to suspend, and from the
context menu that pops up, choose Power > Suspend .
‣ To resume a VM, context-click the VM that you want to resume, and from the context
menu that pops up, choose Power > Power On .
Note: If the GPU instance is being used by another process, this command fails. In this
situation, stop all processes that are using the GPU instance and retry the command.
gpu-instance-id
The GPU instance ID that specifies the GPU instance within which you want to
create the compute instance.
Note: If the GPU instance is being used by another process, this command fails. In this
situation, stop all processes that are using the GPU and retry the command.
+-----------------------------------------------------------------------------+
| MIG devices: |
+------------------+----------------------+-----------+-----------------------+
| GPU GI CI MIG | Memory-Usage | Vol| Shared |
| ID ID Dev | BAR1-Usage | SM Unc| CE ENC DEC OFA JPG|
| | | ECC| |
|==================+======================+===========+=======================|
| 0 0 0 0 | 1058MiB / 10235MiB | 28 0 | 2 0 1 0 0 |
| | 0MiB / 4096MiB | | |
+------------------+----------------------+-----------+-----------------------+
+-----------------------------------------------------------------------------+
| Processes: |
| GPU GI CI PID Type Process name GPU Memory |
| ID ID Usage |
|=============================================================================|
| No running processes found |
+-----------------------------------------------------------------------------+
This example confirms that two MIG 1c.2g.10gb compute instances were created on
GPU instance 0.
$ nvidia-smi
+-----------------------------------------------------------------------------+
| MIG devices: |
+------------------+----------------------+-----------+-----------------------+
| GPU GI CI MIG | Memory-Usage | Vol| Shared |
| ID ID Dev | BAR1-Usage | SM Unc| CE ENC DEC OFA JPG|
| | | ECC| |
|==================+======================+===========+=======================|
| 0 0 0 0 | 1058MiB / 10235MiB | 14 0 | 2 0 1 0 0 |
| | 0MiB / 4096MiB | | |
+------------------+ +-----------+-----------------------+
| 0 0 1 1 | | 14 0 | 2 0 1 0 0 |
| | | | |
+------------------+----------------------+-----------+-----------------------+
+-----------------------------------------------------------------------------+
| Processes: |
| GPU GI CI PID Type Process name GPU Memory |
| ID ID Usage |
|=============================================================================|
| No running processes found |
+-----------------------------------------------------------------------------+
The setting of this parameter is preserved after a guest VM is restarted and after the
hypervisor host is restarted.
Enabling NVIDIA CUDA Toolkit Debuggers for NVIDIA vGPU on Red Hat
Enterprise Linux KVM
Set the enable_debugging vGPU plugin parameter for the mdev device file that
represents the vGPU that is assigned to the VM to 1 as explained in Setting vGPU Plugin
Parameters on a Linux with KVM Hypervisor.
The setting of this parameter is preserved after a guest VM is restarted. However, this
parameter is reset to its default value after the hypervisor host is restarted.
vgpu-id
A positive integer that identifies the vGPU assigned to the VM. For the first vGPU
assigned to a VM, vgpu-id is 0. For example, if two vGPUs are assigned to a VM and you
are enabling debuggers for both vGPUs, set pciPassthru0.cfg.enable_debugging
and pciPassthru1.cfg.enable_debugging to 1.
The setting of this parameter is preserved after a guest VM is restarted. However, this
parameter is reset to its default value after the hypervisor host is restarted.
Note: Enabling profiling for a VM gives the VM access to the GPU’s global performance
counters, which may include activity from other VMs executing on the same GPU. Enabling
profiling for a VM also allows the VM to lock clocks on the GPU, which impacts all other
VMs executing on the same GPU.
Because NVIDIA CUDA Toolkit profilers can be used on only one VM at a time, you should
enable them for only one VM assigned a vGPU on a GPU. However, NVIDIA vGPU software
cannot enforce this requirement. If NVIDIA CUDA Toolkit profilers are enabled on more
than one VM assigned a vGPU on a GPU, profiling data is collected only for the first VM to
start the profiler.
The setting of this parameter is preserved after a guest VM is restarted and after the
hypervisor host is restarted.
Enabling NVIDIA CUDA Toolkit Profilers for NVIDIA vGPU on Red Hat
Enterprise Linux KVM
Set the enable_profiling vGPU plugin parameter for the mdev device file that
represents the vGPU that is assigned to the VM to 1 as explained in Setting vGPU Plugin
Parameters on a Linux with KVM Hypervisor.
The setting of this parameter is preserved after a guest VM is restarted. However, this
parameter is reset to its default value after the hypervisor host is restarted.
NVIDIA vGPU software enables you to monitor the performance of physical GPUs and
virtual GPUs from the hypervisor and from within individual guest VMs.
You can use several tools for monitoring GPU performance:
‣ From any supported hypervisor, and from a guest VM that is running a 64-bit edition
of Windows or Linux, you can use NVIDIA System Management Interface, nvidia-smi.
‣ From Citrix Hypervisor, you can use Citrix XenCenter.
‣ From a Windows guest VM, you can use these tools:
‣ Windows Performance Monitor
‣ Windows Management Instrumentation (WMI)
‣ From a hypervisor command shell, such as the Citrix Hypervisor dom0 shell or VMware
ESXi host shell, nvidia-smi reports management information for NVIDIA physical
GPUs and virtual GPUs present in the system.
Note: When run from a hypervisor command shell, nvidia-smi will not list any GPU
that is currently allocated for GPU pass-through.
‣ From a guest VM, nvidia-smi retrieves usage statistics for vGPUs or pass-through
GPUs that are assigned to the VM.
From a Windows guest VM, you can run nvidia-smi from a command prompt by
changing to the C:\Program Files\NVIDIA Corporation\NVSMI folder and running
the nvidia-smi.exe command.
Note: You cannot monitor from the hypervisor the performance of GPUs that are being
used for GPU pass-through. You can monitor the performance of pass-through GPUs only
from within the guest VM that is using them.
Each vGPU instance is reported in the Compute processes section, together with its
physical GPU index and the amount of frame-buffer memory assigned to it.
In the example that follows, three vGPUs are running in the system: One vGPU is running
on each of the physical GPUs 0, 1, and 2.
[root@vgpu ~]# nvidia-smi
Fri Nov 10 09:26:18 2023
+-----------------------------------------------------------------------------+
| NVIDIA-SMI 470.223.02 Driver Version: 470.223.02 |
|-------------------------------+----------------------+----------------------+
| GPU Name Persistence-M| Bus-Id Disp.A | Volatile Uncorr. ECC |
| Fan Temp Perf Pwr:Usage/Cap| Memory-Usage | GPU-Util Compute M. |
|===============================+======================+======================|
| 0 Tesla M60 On | 0000:83:00.0 Off | Off |
| N/A 31C P8 23W / 150W | 1889MiB / 8191MiB | 7% Default |
+-------------------------------+----------------------+----------------------+
| 1 Tesla M60 On | 0000:84:00.0 Off | Off |
| N/A 26C P8 23W / 150W | 926MiB / 8191MiB | 9% Default |
+-------------------------------+----------------------+----------------------+
| 2 Tesla M10 On | 0000:8A:00.0 Off | N/A |
| N/A 23C P8 10W / 53W | 1882MiB / 8191MiB | 12% Default |
+-------------------------------+----------------------+----------------------+
| 3 Tesla M10 On | 0000:8B:00.0 Off | N/A |
| N/A 26C P8 10W / 53W | 10MiB / 8191MiB | 0% Default |
+-------------------------------+----------------------+----------------------+
| 4 Tesla M10 On | 0000:8C:00.0 Off | N/A |
| N/A 34C P8 10W / 53W | 10MiB / 8191MiB | 0% Default |
+-------------------------------+----------------------+----------------------+
| 5 Tesla M10 On | 0000:8D:00.0 Off | N/A |
| N/A 32C P8 10W / 53W | 10MiB / 8191MiB | 0% Default |
+-------------------------------+----------------------+----------------------+
+-----------------------------------------------------------------------------+
| Processes: GPU Memory |
| GPU PID Type Process name Usage |
|=============================================================================|
| 0 11924 C+G /usr/lib64/xen/bin/vgpu 1856MiB |
| 1 11903 C+G /usr/lib64/xen/bin/vgpu 896MiB |
| 2 11908 C+G /usr/lib64/xen/bin/vgpu 1856MiB |
+-----------------------------------------------------------------------------+
[root@vgpu ~]#
+-------------------------------+--------------------------------+------------+
| 4 Tesla M10 | 0000:8C:00.0 | 0% |
+-------------------------------+--------------------------------+------------+
| 5 Tesla M10 | 0000:8D:00.0 | 0% |
+-------------------------------+--------------------------------+------------+
[root@vgpu ~]#
Statistic Column
3D/Compute sm
Statistic Column
Memory controller bandwidth mem
Each reported percentage is the percentage of the physical GPU’s capacity that a vGPU
is using. For example, a vGPU that uses 20% of the GPU’s graphics engine’s capacity will
report 20%.
To modify the reporting frequency, use the –l or --loop option.
To limit monitoring to a subset of the GPUs on the platform, use the –i or --id option to
select one or more vGPUs.
[root@vgpu ~]# nvidia-smi vgpu -u
# gpu vgpu sm mem enc dec
# Idx Id % % % %
0 11924 6 3 0 0
1 11903 8 3 0 0
2 11908 10 4 0 0
3 - - - - -
4 - - - - -
5 - - - - -
0 11924 6 3 0 0
1 11903 9 3 0 0
2 11908 10 4 0 0
3 - - - - -
4 - - - - -
5 - - - - -
0 11924 6 3 0 0
1 11903 8 3 0 0
2 11908 10 4 0 0
3 - - - - -
4 - - - - -
5 - - - - -
^C[root@vgpu ~]#
For each application on each vGPU, the usage statistics in the following table are reported
once every second. Each application is identified by its process ID and process name.
The table also shows the name of the column in the command output under which each
statistic is reported.
Statistic Column
3D/Compute sm
Each reported percentage is the percentage of the physical GPU’s capacity used by
an application running on a vGPU that resides on the physical GPU. For example, an
application that uses 20% of the GPU’s graphics engine’s capacity will report 20%.
To modify the reporting frequency, use the –l or --loop option.
To limit monitoring to a subset of the GPUs on the platform, use the –i or --id option to
select one or more vGPUs.
[root@vgpu ~]# nvidia-smi vgpu -p
# GPU vGPU process process sm mem enc dec
# Idx Id Id name % % % %
0 38127 1528 dwm.exe 0 0 0 0
1 37408 4232 DolphinVS.exe 32 25 0 0
1 257869 4432 FurMark.exe 16 12 0 0
1 257969 4552 FurMark.exe 48 37 0 0
0 38127 1528 dwm.exe 0 0 0 0
1 37408 4232 DolphinVS.exe 16 12 0 0
1 257911 656 DolphinVS.exe 32 24 0 0
1 257969 4552 FurMark.exe 48 37 0 0
0 38127 1528 dwm.exe 0 0 0 0
1 257869 4432 FurMark.exe 38 30 0 0
1 257911 656 DolphinVS.exe 19 14 0 0
1 257969 4552 FurMark.exe 38 30 0 0
0 38127 1528 dwm.exe 0 0 0 0
1 257848 3220 Balls64.exe 16 12 0 0
1 257869 4432 FurMark.exe 16 12 0 0
1 257911 656 DolphinVS.exe 16 12 0 0
1 257969 4552 FurMark.exe 48 37 0 0
0 38127 1528 dwm.exe 0 0 0 0
1 257911 656 DolphinVS.exe 32 25 0 0
1 257969 4552 FurMark.exe 64 50 0 0
0 38127 1528 dwm.exe 0 0 0 0
1 37408 4232 DolphinVS.exe 16 12 0 0
1 257911 656 DolphinVS.exe 16 12 0 0
1 257969 4552 FurMark.exe 64 49 0 0
0 38127 1528 dwm.exe 0 0 0 0
1 37408 4232 DolphinVS.exe 16 12 0 0
1 257869 4432 FurMark.exe 16 12 0 0
1 257969 4552 FurMark.exe 64 49 0 0
[root@vgpu ~]#
To monitor the encoder sessions for processes running on multiple vGPUs, run nvidia-
smi vgpu with the –es or --encodersessions option.
For each encoder session, the following statistics are reported once every second:
‣ GPU ID
‣ vGPU ID
‣ Encoder session ID
‣ PID of the process in the VM that created the encoder session
‣ Codec type, for example, H.264 or H.265
For each FBC session, the following statistics are reported once every second:
‣ GPU ID
‣ vGPU ID
‣ FBC session ID
‣ PID of the process in the VM that created the FBC session
2 - - - - - - -
- - - - - - -
# GPU vGPU Session Process Display Session Diff. Map Class. Map
Capture Max H Max V H V Average Average
# Idx Id Id Id Ordinal Type State State
Mode Res Res Res Res FPS Latency(us)
0 - - - - - - -
- - - - - - -
1 3251634178 1 3984 0 ToSys Disabled Disabled
Blocking 4096 2160 0 0 0 0
2 - - - - - - -
- - - - - - -
0 - - - - - - -
- - - - - - -
1 3251634178 1 3984 0 ToSys Disabled Disabled
Blocking 4096 2160 0 0 0 0
2 - - - - - - -
- - - - - - -
0 - - - - - - -
- - - - - - -
1 3251634178 1 3984 0 ToSys Disabled Disabled
Blocking 4096 2160 0 0 0 0
2 - - - - - - -
- - - - - - -
0 - - - - - - -
- - - - - - -
1 3251634178 1 3984 0 ToSys Disabled Disabled
Blocking 4096 2160 0 0 0 0
2 - - - - - - -
- - - - - - -
0 - - - - - - -
- - - - - - -
1 3251634178 1 3984 0 ToSys Disabled Disabled
Blocking 4096 2160 0 0 0 0
2 - - - - - - -
- - - - - - -
0 - - - - - - -
- - - - - - -
1 3251634178 1 3984 0 ToSys Disabled Disabled
Blocking 4096 2160 1600 900 135 7400
2 - - - - - - -
- - - - - - -
0 - - - - - - -
- - - - - - -
1 3251634178 1 3984 0 ToSys Disabled Disabled
Blocking 4096 2160 1600 900 227 4403
2 - - - - - - -
- - - - - - -
0 - - - - - - -
- - - - - - -
1 3251634178 1 3984 0 ToSys Disabled Disabled
Blocking 4096 2160 1600 900 227 4403
2 - - - - - - -
- - - - - - -
0 - - - - - - -
- - - - - - -
1 3251634178 1 3984 0 ToSys Disabled Disabled
Blocking 4096 2160 0 0 0 0
2 - - - - - - -
- - - - - - -
0 - - - - - - -
- - - - - - -
1 3251634178 1 3984 0 ToSys Disabled Disabled
Blocking 4096 2160 0 0 0 0
2 - - - - - - -
- - - - - - -
# GPU vGPU Session Process Display Session Diff. Map Class. Map
Capture Max H Max V H V Average Average
# Idx Id Id Id Ordinal Type State State
Mode Res Res Res Res FPS Latency(us)
0 - - - - - - -
- - - - - - -
1 3251634178 1 3984 0 ToSys Disabled Disabled
Blocking 4096 2160 0 0 0 0
2 - - - - - - -
- - - - - - -
0 - - - - - - -
- - - - - - -
1 3251634178 1 3984 0 ToSys Disabled Disabled
Blocking 4096 2160 0 0 0 0
2 - - - - - - -
- - - - - - -
0 - - - - - - -
- - - - - - -
1 3251634178 1 3984 0 ToSys Disabled Disabled
Blocking 4096 2160 0 0 0 0
2 - - - - - - -
- - - - - - -
0 - - - - - - -
- - - - - - -
1 3251634178 1 3984 0 ToSys Disabled Disabled
Blocking 4096 2160 0 0 0 0
2 - - - - - - -
- - - - - - -
0 - - - - - - -
- - - - - - -
1 3251634178 1 3984 0 ToSys Disabled Disabled
Blocking 4096 2160 0 0 0 0
2 - - - - - - -
- - - - - - -
0 - - - - - - -
- - - - - - -
1 3251634178 1 3984 0 ToSys Disabled Disabled
Blocking 4096 2160 0 0 0 0
2 - - - - - - -
- - - - - - -
0 - - - - - - -
- - - - - - -
1 3251634178 1 3984 0 ToSys Disabled Disabled
Blocking 4096 2160 0 0 0 0
2 - - - - - - -
- - - - - - -
0 - - - - - - -
- - - - - - -
1 3251634178 1 3984 0 ToSys Disabled Disabled
Blocking 4096 2160 0 0 0 0
2 - - - - - - -
- - - - - - -
0 - - - - - - -
- - - - - - -
1 3251634178 1 3984 0 ToSys Disabled Disabled
Blocking 4096 2160 0 0 0 0
2 - - - - - - -
- - - - - - -
0 - - - - - - -
- - - - - - -
1 3251634178 1 3984 0 ToSys Disabled Disabled
Blocking 4096 2160 0 0 0 0
2 - - - - - - -
- - - - - - -
^C[root@vgpu ~]#
To view detailed information about the supported vGPU types, add the –v or --verbose
option:
[root@vgpu ~]# nvidia-smi vgpu -s -i 0 -v | less
GPU 00000000:83:00.0
vGPU Type ID : 0xb
Name : GRID M60-0B
Class : NVS
Max Instances : 16
Device ID : 0x13f210de
Sub System ID : 0x13f21176
FB Memory : 512 MiB
Display Heads : 2
Maximum X Resolution : 2560
Maximum Y Resolution : 1600
Frame Rate Limit : 45 FPS
GRID License : GRID-Virtual-PC,2.0;GRID-Virtual-WS,2.0;GRID-
Virtual-WS-Ext,2.0;Quadro-Virtual-DWS,5.0
vGPU Type ID : 0xc
Name : GRID M60-0Q
Class : Quadro
Max Instances : 16
Device ID : 0x13f210de
Sub System ID : 0x13f2114c
FB Memory : 512 MiB
Display Heads : 2
Maximum X Resolution : 2560
Maximum Y Resolution : 1600
Frame Rate Limit : 60 FPS
GRID License : GRID-Virtual-WS,2.0;GRID-Virtual-WS-Ext,2.0;Quadro-
Virtual-DWS,5.0
vGPU Type ID : 0xd
Name : GRID M60-1A
Class : NVS
Max Instances : 8
…
[root@vgpu ~]#
This property is a dynamic property that varies for each GPU depending on whether MIG
mode is enabled for the GPU.
‣ If MIG mode is not enabled for the GPU, or if the GPU does not support MIG, this
property reflects the number and type of vGPUs that are already running on the GPU.
‣ If no vGPUs are running on the GPU, all vGPU types that the GPU supports are
listed.
‣ If one or more vGPUs are running on the GPU, but the GPU is not fully loaded, only
the type of the vGPUs that are already running is listed.
‣ If the GPU is fully loaded, no vGPU types are listed.
‣ If MIG mode is enabled for the GPU, the result reflects the number and type of GPU
instances on which no vGPUs are already running.
To view detailed information about the vGPU types that can currently be created, add the
–v or --verbose option.
Counters are listed for each physical GPU not currently being used for GPU pass-through.
‣ 3D/Compute
‣ Memory controller
‣ Video encoder
‣ Video decoder
‣ Frame buffer usage
Other metrics normally present in a GPU are not applicable to a vGPU and are reported as
zero or N/A, depending on the tool that you are using.
‣ GPU
‣ Video encoder
‣ Video decoder
‣ Frame buffer
To use nvidia-smi to retrieve statistics for the total resource usage by all applications
running in the VM, run the following command:
nvidia-smi dmon
The following example shows the result of running nvidia-smi dmon from within a
Windows guest VM.
On vGPUs, the following GPU performance counters read as 0 because they are not
applicable to vGPUs:
‣ % Bus Usage
‣ % Cooler rate
‣ Core Clock MHz
‣ Fan Speed
‣ Memory Clock MHz
‣ PCI-E current speed to GPU Mbps
‣ PCI-E current width to GPU
‣ PCI-E downstream width to GPU
‣ Power Consumption mW
‣ Temperature C
driver package. After the driver is installed, NVWMI help information in Windows Help
format is available as follows:
C:\Program Files\NVIDIA Corporation\NVIDIA WMI Provider>nvwmi.chm
Any WMI-enabled application can access these metrics. The following example shows
GPU metrics in the third-party application WMI Explorer, which is available for download
from the from the CodePlex WMI Explorer page.
On vGPUs, some instance properties of the following classes do not apply to vGPUs:
‣ Gpu
‣ PcieLink
NVIDIA GPUs based on the NVIDIA Maxwell™ graphic architecture implement a best
effort vGPU scheduler that aims to balance performance across vGPUs. The best effort
scheduler allows a vGPU to use GPU processing cycles that are not being used by other
vGPUs. Under some circumstances, a VM running a graphics-intensive application may
adversely affect the performance of graphics-light applications running in other VMs.
GPUs based on NVIDIA GPU architectures after the Maxwell architecture additionally
support equal share and fixed share vGPU schedulers. These schedulers impose a limit on
GPU processing cycles used by a vGPU, which prevents graphics-intensive applications
running in one VM from affecting the performance of graphics-light applications running
in other VMs. On GPUs that support multiple vGPU schedulers, you can select the vGPU
scheduler to use. You can also set the length of the time slice for the equal share and
fixed share vGPU schedulers.
Note: If you use the equal share or fixed share vGPU scheduler, the frame-rate limiter
(FRL) is disabled.
The best effort scheduler is the default scheduler for all supported GPU architectures.
If you are unsure of the NVIDIA GPU architecture of your GPU, consult the release notes
for your hypervisor at NVIDIA Virtual GPU Software Documentation.
may increase as other vGPUs on the same GPU are stopped, or decrease as other
vGPUs are started on the same GPU.
Fixed share scheduler
Each vGPU is given a fixed share of the physical GPU's processing cycles, the amount
of which depends on the vGPU type, which in turn determines the maximum number
of vGPUs per physical GPU. For example, the maximum number of T4-4C vGPUs per
physical GPU is 4. When the scheduling policy is fixed share, each T4-4C vGPU is given
one quarter, or 25%, the physical GPU's processing cycles. As vGPUs are added to or
removed from a GPU, the share of the GPU's processing cycles allocated to each vGPU
remains constant. As a result, the performance of a vGPU remains unchanged as other
vGPUs are stopped or started on the same GPU.
‣ For workloads that require low latency, a shorter time slice is optimal. Typically, these
workloads are applications that must generate output at a fixed interval, such as
graphics applications that generate output at a frame rate of 60 FPS. These workloads
are sensitive to latency and should be allowed to run at least once per interval. A
shorter time slice reduces latency and improves responsiveness by causing the
scheduler to switch more frequently between VMs.
‣ For workloads that require maximum throughput, a longer time slice is optimal.
Typically, these workloads are applications that must complete their work as quickly as
possible and do not require responsiveness, such as CUDA applications. A longer time
slice increases throughput by preventing frequent switching between VMs.
Note: You can change the vGPU scheduling behavior only on GPUs that support multiple
vGPU schedulers, that is, GPUs based on NVIDIA GPU architectures after the Maxwell
architecture.
Type
Dword
Contents
Value Meaning
0x00 (default) Best effort scheduler
0x01 Equal share scheduler with the default time slice length
0x00TT0001 Equal share scheduler with a user-defined time slice length TT
0x11 Fixed share scheduler with the default time slice length
0x00TT0011 Fixed share scheduler with a user-defined time slice length TT
The default time slice length depends on the maximum number of vGPUs per physical
GPU allowed for the vGPU type.
TT
Two hexadecimal digits in the range 01 to 1E that set the length of the time slice in
milliseconds (ms) for the equal share and fixed share schedulers. The minimum length
is 1 ms and the maximum length is 30 ms.
If TT is 00, the length is set to the default length for the vGPU type.
If TT is greater than 1E, the length is set to 30 ms.
Examples
This example sets the vGPU scheduler to equal share scheduler with the default time
slice length.
RmPVMRL=0x01
This example sets the vGPU scheduler to equal share scheduler with a time slice that is 3
ms long.
RmPVMRL=0x00030001
This example sets the vGPU scheduler to fixed share scheduler with the default time slice
length.
RmPVMRL=0x11
This example sets the vGPU scheduler to fixed share scheduler with a time slice that is 24
(0x18) ms long.
RmPVMRL=0x00180011
‣ BEST_EFFORT
‣ EQUAL_SHARE
‣ FIXED_SHARE
If the scheduling behavior is equal share or fixed share, the scheduler time slice in ms
is also displayed.
This example gets the scheduling behavior of the GPUs in a system in which the
behavior of one GPU is set to best effort, one GPU is set to equal share, and one GPU
is set to fixed share.
$ dmesg | grep NVRM | grep scheduler
2020-10-05T02:58:08.928Z cpu79:2100753)NVRM: GPU at 0000:3d:00.0 has software
scheduler DISABLED with policy BEST_EFFORT.
2020-10-05T02:58:09.818Z cpu79:2100753)NVRM: GPU at 0000:5e:00.0 has software
scheduler ENABLED with policy EQUAL_SHARE.
NVRM: Software scheduler timeslice set to 1 ms.
2020-10-05T02:58:12.115Z cpu79:2100753)NVRM: GPU at 0000:88:00.0 has software
scheduler ENABLED with policy FIXED_SHARE.
NVRM: Software scheduler timeslice set to 1 ms.
‣ On Citrix Hypervisor, Red Hat Enterprise Linux KVM, or Red Hat Virtualization
(RHV), add the following entry to the /etc/modprobe.d/nvidia.conf file.
options nvidia NVreg_RegistryDwords="RmPVMRL=value"
value
The value that sets the GPU scheduling policy and the length of the time slice that
you want, for example:
0x01
Sets the vGPU scheduling policy to equal share scheduler with the default time
slice length.
0x00030001
Sets the GPU scheduling policy to equal share scheduler with a time slice that is
3 ms long.
0x11
Sets the vGPU scheduling policy to fixed share scheduler with the default time
slice length.
0x00180011
Sets the GPU scheduling policy to fixed share scheduler with a time slice that is
24 (0x18) ms long.
For all supported values, see RmPVMRL Registry Key.
3. Reboot your hypervisor host machine.
Confirm that the scheduling behavior was changed as required as explained in Getting
the Current Time-Sliced vGPU Scheduling Behavior for All GPUs.
‣ On Citrix Hypervisor, Red Hat Enterprise Linux KVM, or Red Hat Virtualization
(RHV), add the -D option to display the PCI domain and the -d 10de: option to
display information only for NVIDIA GPUs.
# lspci -D -d 10de:
‣ On VMware vSphere, pipe the output of lspci to the grep command to display
information only for NVIDIA GPUs.
# lspci | grep NVIDIA
The NVIDIA GPU listed in this example has the PCI domain 0000 and BDF 86:00.0.
0000:86:00.0 3D controller: NVIDIA Corporation GP104GL [Tesla P4] (rev a1)
3. Use the module parameter NVreg_RegistryDwordsPerDevice to set the pci and
RmPVMRL registry keys for each GPU.
‣ On Citrix Hypervisor, Red Hat Enterprise Linux KVM, or RHV, add the following
entry to the /etc/modprobe.d/nvidia.conf file.
options nvidia NVreg_RegistryDwordsPerDevice="pci=pci-domain:pci-
bdf;RmPVMRL=value
[;pci=pci-domain:pci-bdf;RmPVMRL=value...]"
pci-domain
The PCI domain of the GPU.
pci-bdf
The PCI device BDF of the GPU.
value
The value that sets the GPU scheduling policy and the length of the time slice that
you want, for example:
0x01
Sets the GPU scheduling policy to equal share scheduler with the default time
slice length.
0x00030001
Sets the GPU scheduling policy to equal share scheduler with a time slice that is
3 ms long.
0x11
Sets the GPU scheduling policy to fixed share scheduler with the default time
slice length.
0x00180011
Sets the GPU scheduling policy to fixed share scheduler with a time slice that is
24 (0x18) ms long.
For all supported values, see RmPVMRL Registry Key.
This example adds an entry to the /etc/modprobe.d/nvidia.conf file to change the
scheduling behavior of a single GPU. The entry sets the GPU scheduling policy of the
GPU at PCI domain 0000 and BDF 86:00.0 to fixed share scheduler with the default
time slice length.
options nvidia NVreg_RegistryDwordsPerDevice=
"pci=0000:86:00.0;RmPVMRL=0x11"
This example changes the scheduling behavior of a single GPU on a hypervisor host
that is running VMware vSphere. The command sets the scheduling policy of the GPU
at PCI domain 0000 and BDF 15:00.0 to fixed share scheduler with the default time
slice length.
# esxcli system module parameters set -m nvidia -p \
"NVreg_RegistryDwordsPerDevice=pci=0000:15:00.0;RmPVMRL=0x11[;pci=0000:15:00.0;RmPVMRL=0x11]"
This example changes the scheduling behavior of a single GPU on a hypervisor host
that is running VMware vSphere. The command sets the scheduling policy of the GPU
at PCI domain 0000 and BDF 15:00.0 to fixed share scheduler with a time slice that is
24 (0x18) ms long.
# esxcli system module parameters set -m nvidia -p \
"NVreg_RegistryDwordsPerDevice=pci=0000:15:00.0;RmPVMRL=0x11[;pci=0000:15:00.0;RmPVMRL=0x00180011]"
4. Reboot your hypervisor host machine.
Confirm that the scheduling behavior was changed as required as explained in Getting
the Current Time-Sliced vGPU Scheduling Behavior for All GPUs.
‣ On Citrix Hypervisor, Red Hat Enterprise Linux KVM, or Red Hat Virtualization
(RHV), comment out the entries in the /etc/modprobe.d/nvidia.conf file that set
RmPVMRL by prefixing each entry with the # character.
‣ On VMware vSphere, set the module parameter to an empty string.
# esxcli system module parameters set -m nvidia -p "module-parameter="
module-parameter
The module parameter to set, which depends on whether the scheduling
behavior was changed for all GPUs or select GPUs:
This chapter describes basic troubleshooting steps for NVIDIA vGPU on Citrix Hypervisor,
Red Hat Enterprise Linux KVM, Red Hat Virtualization (RHV), and VMware vSphere, and
how to collect debug information when filing a bug report.
‣ On Citrix Hypervisor, Red Hat Enterprise Linux KVM, and RHV, use lsmod:
[root@xenserver ~]# lsmod|grep nvidia
nvidia 9604895 84
i2c_core 20294 2 nvidia,i2c_i801
[root@xenserver ~]#
‣ On VMware vSphere, use vmkload_mod:
[root@esxi:~] vmkload_mod -l | grep nvidia
nvidia 5 8420
2. If the nvidia driver is not listed in the output, check dmesg for any load-time errors
reported by the driver (see Examining NVIDIA kernel driver output).
3. On Citrix Hypervisor, Red Hat Enterprise Linux KVM, and RHV, also use the rpm -q
command to verify that the NVIDIA GPU Manager package is correctly installed.
rpm -q vgpu-manager-rpm-package-name
vgpu-manager-rpm-package-name
The RPM package name of the NVIDIA GPU Manager package, for example NVIDIA-
vGPU-NVIDIA-vGPU-CitrixHypervisor-8.2-470.223.02 for Citrix Hypervisor.
This example verifies that the NVIDIA GPU Manager package for Citrix Hypervisor is
correctly installed.
[root@xenserver ~]# rpm –q NVIDIA-vGPU-NVIDIA-vGPU-CitrixHypervisor-8.2-470.223.02
[root@xenserver ~]#
If an existing NVIDIA GRID package is already installed and you don’t select the
upgrade (-U) option when installing a newer GRID package, the rpm command will
return many conflict errors.
Preparing packages for installation...
file /usr/bin/nvidia-smi from install of NVIDIA-vGPU-NVIDIA-vGPU-
CitrixHypervisor-8.2-470.223.02.x86_64 conflicts with file from package NVIDIA-
vGPU-xenserver-8.2-470.199.03.x86_64
file /usr/lib/libnvidia-ml.so from install of NVIDIA-vGPU-NVIDIA-vGPU-
CitrixHypervisor-8.2-470.223.02.x86_64 conflicts with file from package NVIDIA-
vGPU-xenserver-8.2-470.199.03.x86_64
...
For Xen open source/XCP users, if you are reporting a domain issue,
please run: nvidia-bug-report.sh --domain-name <"domain_name">
Running nvidia-bug-report.sh...
If the bug report script hangs after this point consider running with
--safe-mode command line argument.
complete
[root@xenserver ~]#
MIG-Backed C-Series Virtual GPU Types for NVIDIA A100 PCIe 40GB
Required license edition: vCS or vWS
For details of GPU instance profiles, see NVIDIA Multi-Instance GPU User Guide.
Time-Sliced C-Series Virtual GPU Types for NVIDIA A100 PCIe 40GB
Required license edition: vCS or vWS
These vGPU types support a single display with a fixed maximum resolution.
Virtual
Frame Maximum Maximum Maximum
Virtual Intended Displays
Buffer vGPUs vGPUs Display
GPU Type Use Case per
(MB) per GPU per Board Resolution
vGPU
Training 2
A100-40C 40960 1 1 4096×2160 1
Workloads
Training 2
A100-20C 20480 2 2 4096×2160 1
Workloads
Training 2
A100-10C 10240 4 4 4096×2160 1
Workloads
Training 2
A100-8C 8192 5 5 4096×2160 1
Workloads
Inference 2
A100-5C 5120 8 8 4096×2160 1
Workloads
Inference 2
A100-4C 4096 10 10 4096×2160 1
Workloads
MIG-Backed C-Series Virtual GPU Types for NVIDIA A100 HGX 40GB
Required license edition: vCS or vWS
For details of GPU instance profiles, see NVIDIA Multi-Instance GPU User Guide.
Time-Sliced C-Series Virtual GPU Types for NVIDIA A100 HGX 40GB
Required license edition: vCS or vWS
These vGPU types support a single display with a fixed maximum resolution.
Virtual
Frame Maximum Maximum Maximum
Virtual Intended Displays
Buffer vGPUs vGPUs Display
GPU Type Use Case per
(MB) per GPU per Board Resolution
vGPU
Training 2
A100X-40C 40960 1 1 4096×2160 1
Workloads
Training 2
A100X-20C 20480 2 2 4096×2160 1
Workloads
Training 2
A100X-10C 10240 4 4 4096×2160 1
Workloads
Training 2
A100X-8C 8192 5 5 4096×2160 1
Workloads
Inference 2
A100X-5C 5120 8 8 4096×2160 1
Workloads
Inference 2
A100X-4C 4096 10 10 4096×2160 1
Workloads
MIG-Backed C-Series Virtual GPU Types for NVIDIA A100 PCIe 80GB
Required license edition: vCS or vWS
For details of GPU instance profiles, see NVIDIA Multi-Instance GPU User Guide.
Time-Sliced C-Series Virtual GPU Types for NVIDIA A100 PCIe 80GB
Required license edition: vCS or vWS
These vGPU types support a single display with a fixed maximum resolution.
Virtual
Frame Maximum Maximum Maximum
Virtual Intended Displays
Buffer vGPUs vGPUs Display
GPU Type Use Case per
(MB) per GPU per Board Resolution
vGPU
Training 2
A100D-80C 81920 1 1 4096×2160 1
Workloads
Training 2
A100D-40C 40960 2 2 4096×2160 1
Workloads
Training 2
A100D-20C 20480 4 4 4096×2160 1
Workloads
Virtual
Frame Maximum Maximum Maximum
Virtual Intended Displays
Buffer vGPUs vGPUs Display
GPU Type Use Case per
(MB) per GPU per Board Resolution
vGPU
Inference 2
A100D-16C 16384 5 5 4096×2160 1
Workloads
Training 2
A100D-10C 10240 8 8 4096×2160 1
Workloads
Training 2
A100D-8C 8192 10 10 4096×2160 1
Workloads
Inference 2
A100D-4C 4096 20 20 4096×2160 1
Workloads
MIG-Backed C-Series Virtual GPU Types for NVIDIA A100 HGX 80GB
Required license edition: vCS or vWS
For details of GPU instance profiles, see NVIDIA Multi-Instance GPU User Guide.
Time-Sliced C-Series Virtual GPU Types for NVIDIA A100 HGX 80GB
Required license edition: vCS or vWS
These vGPU types support a single display with a fixed maximum resolution.
Virtual
Frame Maximum Maximum Maximum
Virtual Intended Displays
Buffer vGPUs vGPUs Display
GPU Type Use Case per
(MB) per GPU per Board Resolution
vGPU
Training 2
A100DX-80C 81920 1 1 4096×2160 1
Workloads
Training 2
A100DX-40C 40960 2 2 4096×2160 1
Workloads
Training 2
A100DX-20C 20480 4 4 4096×2160 1
Workloads
Inference 2
A100DX-16C 16384 5 5 4096×2160 1
Workloads
Training 2
A100DX-10C 10240 8 8 4096×2160 1
Workloads
Training 2
A100DX-8C 8192 10 10 4096×2160 1
Workloads
Inference 2
A100DX-4C 4096 20 20 4096×2160 1
Workloads
Maximum Virtual
Frame Maximum
Virtual Intended vGPUs Available Display Displays
Buffer vGPUs
GPU Type Use Case per Pixels Resolution per
(MB) per GPU
Board vGPU
7680×4320 2
Virtual
A40-48Q 49152 1 1 66355200 5120×2880
Workstations 4
or lower
7680×4320 2
Virtual
A40-24Q 24576 2 2 66355200 5120×2880
Workstations 4
or lower
7680×4320 2
Virtual
A40-16Q 16384 3 3 66355200 5120×2880
Workstations 4
or lower
7680×4320 2
Virtual
A40-12Q 12288 4 4 66355200 5120×2880
Workstations 4
or lower
7680×4320 2
Virtual
A40-8Q 8192 6 6 66355200 5120×2880
Workstations 4
or lower
7680×4320 1
Virtual
A40-6Q 6144 8 8 58982400 5120×2880
Workstations 4
or lower
7680×4320 1
Virtual
A40-4Q 4096 12 12 58982400 5120×2880
Workstations 4
or lower
7680×4320 1
Virtual 5120×2880 2
A40-3Q 3072 16 16 35389440
Workstations 4096×2160
4
or lower
7680×4320 1
Virtual 5120×2880 2
A40-2Q 2048 24 24 35389440
Workstations 4096×2160
4
or lower
Virtual 5120×2880 1
A40-1Q 1024 7 32 17694720
32
Workstations 4096×2160 2
7
The maximum vGPUs per GPU is limited to 32.
Maximum Virtual
Frame Maximum
Virtual Intended vGPUs Available Display Displays
Buffer vGPUs
GPU Type Use Case per Pixels Resolution per
(MB) per GPU
Board vGPU
3840×2160 2
2560×1600
4
or lower
Maximum Virtual
Frame Maximum
Virtual Intended vGPUs Available Display Displays
Buffer vGPUs
GPU Type Use Case per Pixels Resolution per
(MB) per GPU
Board vGPU
5120×2880 1
4096×2160 2
Virtual
A40-2B 2048 24 24 17694720 3840×2160 2
Desktops
2560×1600
4
or lower
5120×2880 1
4096×2160 1
Virtual
A40-1B 1024 32 32 16384000 3840×2160 1
Desktops
2560×1600 5
4
or lower
Virtual
Frame Maximum Maximum Maximum
Virtual Intended Displays
Buffer vGPUs vGPUs Display
GPU Type Use Case per
(MB) per GPU per Board Resolution
vGPU
Training 2
A40-48C 49152 1 1 4096×2160 1
Workloads
Training 2
A40-24C 24576 2 2 4096×2160 1
Workloads
Training 2
A40-16C 16384 3 3 4096×2160 1
Workloads
Training 2
A40-12C 12288 4 4 4096×2160 1
Workloads
Training 2
A40-8C 8192 6 6 4096×2160 1
Workloads
Training 2
A40-6C 6144 8 8 4096×2160 1
Workloads
Inference 3 2
A40-4C 4096 12 12 4096×2160 1
Workloads
Virtual
Frame Maximum Maximum Maximum
Virtual Intended Displays
Buffer vGPUs vGPUs Display
GPU Type Use Case per
(MB) per GPU per Board Resolution
vGPU
Virtual 6 6
A40-48A 49152 1 1 1280×1024 1
Applications
Virtual 6 6
A40-24A 24576 2 2 1280×1024 1
Applications
Virtual 6 6
A40-16A 16384 3 3 1280×1024 1
Applications
Virtual 6 6
A40-12A 12288 4 4 1280×1024 1
Applications
Virtual 6 6
A40-8A 8192 6 6 1280×1024 1
Applications
Virtual 6 6
A40-6A 6144 8 8 1280×1024 1
Applications
Virtual
Frame Maximum Maximum Maximum
Virtual Intended Displays
Buffer vGPUs vGPUs Display
GPU Type Use Case per
(MB) per GPU per Board Resolution
vGPU
Virtual 6 6
A40-4A 4096 12 12 1280×1024 1
Applications
Virtual 6 6
A40-3A 3072 16 16 1280×1024 1
Applications
Virtual 6 6
A40-2A 2048 24 24 1280×1024 1
Applications
Virtual 7 6 6
A40-1A 1024 32 32 1280×1024 1
Applications
Virtual
Frame Maximum Maximum Maximum
Virtual Intended Displays
Buffer vGPUs vGPUs Display
GPU Type Use Case per
(MB) per GPU per Board Resolution
vGPU
Training 2
A30-24C 24576 1 1 4096×2160 1
Workloads
Training 2
A30-12C 12288 2 2 4096×2160 1
Workloads
Training 2
A30-8C 8192 3 3 4096×2160 1
Workloads
Inference 2
A30-6C 6144 4 4 4096×2160 1
Workloads
Inference 2
A30-4C 4096 6 6 4096×2160 1
Workloads
Maximum Virtual
Frame Maximum
Virtual Intended vGPUs Available Display Displays
Buffer vGPUs
GPU Type Use Case per Pixels Resolution per
(MB) per GPU
Board vGPU
7680×4320 2
Virtual
A16-16Q 16384 1 4 66355200 5120×2880
Workstations 4
or lower
7680×4320 2
Virtual
A16-8Q 8192 2 8 66355200 5120×2880
Workstations 4
or lower
Maximum Virtual
Frame Maximum
Virtual Intended vGPUs Available Display Displays
Buffer vGPUs
GPU Type Use Case per Pixels Resolution per
(MB) per GPU
Board vGPU
7680×4320 1
Virtual
A16-4Q 4096 4 16 58982400 5120×2880
Workstations 4
or lower
7680×4320 1
Virtual 5120×2880 2
A16-2Q 2048 8 32 35389440
Workstations 4096×2160
4
or lower
5120×2880 1
Virtual
4096×2160 2
Desktops,
A16-1Q 1024 16 64 17694720 3840×2160 2
Virtual
Workstations 2560×1600
4
or lower
Maximum Virtual
Frame Maximum
Virtual Intended vGPUs Available Display Displays
Buffer vGPUs
GPU Type Use Case per Pixels Resolution per
(MB) per GPU
Board vGPU
5120×2880 1
4096×2160 2
Virtual
A16-2B 2048 8 32 17694720 3840×2160 2
Desktops
2560×1600
4
or lower
Virtual 5120×2880 1
A16-1B 1024 16 64 16384000
Desktops 4096×2160 1
Maximum Virtual
Frame Maximum
Virtual Intended vGPUs Available Display Displays
Buffer vGPUs
GPU Type Use Case per Pixels Resolution per
(MB) per GPU
Board vGPU
3840×2160 1
2560×1600 5
4
or lower
Virtual
Frame Maximum Maximum Maximum
Virtual Intended Displays
Buffer vGPUs vGPUs Display
GPU Type Use Case per
(MB) per GPU per Board Resolution
vGPU
Training 2
A16-16C 16384 1 4 4096×2160 1
Workloads
Training 2
A16-8C 8192 2 8 4096×2160 1
Workloads
Inference 2
A16-4C 4096 4 16 4096×2160 1
Workloads
Virtual
Frame Maximum Maximum Maximum
Virtual Intended Displays
Buffer vGPUs vGPUs Display
GPU Type Use Case per
(MB) per GPU per Board Resolution
vGPU
Virtual 6 6
A16-16A 16384 1 4 1280×1024 1
Applications
Virtual 6 6
A16-8A 8192 2 8 1280×1024 1
Applications
Virtual 6 6
A16-4A 4096 4 16 1280×1024 1
Applications
Virtual 6 6
A16-2A 2048 8 32 1280×1024 1
Applications
Virtual
Frame Maximum Maximum Maximum
Virtual Intended Displays
Buffer vGPUs vGPUs Display
GPU Type Use Case per
(MB) per GPU per Board Resolution
vGPU
Virtual 6 6
A16-1A 1024 16 64 1280×1024 1
Applications
Maximum Virtual
Frame Maximum
Virtual Intended vGPUs Available Display Displays
Buffer vGPUs
GPU Type Use Case per Pixels Resolution per
(MB) per GPU
Board vGPU
7680×4320 2
Virtual
A10-24Q 24576 1 1 66355200 5120×2880
Workstations 4
or lower
7680×4320 2
Virtual
A10-12Q 12288 2 2 66355200 5120×2880
Workstations 4
or lower
7680×4320 2
Virtual
A10-8Q 8192 3 3 66355200 5120×2880
Workstations 4
or lower
7680×4320 1
Virtual
A10-6Q 6144 4 4 58982400 5120×2880
Workstations 4
or lower
7680×4320 1
Virtual
A10-4Q 4096 6 6 58982400 5120×2880
Workstations 4
or lower
Maximum Virtual
Frame Maximum
Virtual Intended vGPUs Available Display Displays
Buffer vGPUs
GPU Type Use Case per Pixels Resolution per
(MB) per GPU
Board vGPU
7680×4320 1
Virtual 5120×2880 2
A10-3Q 3072 8 8 35389440
Workstations 4096×2160
4
or lower
7680×4320 1
Virtual 5120×2880 2
A10-2Q 2048 12 12 35389440
Workstations 4096×2160
4
or lower
5120×2880 1
4096×2160 2
Virtual
A10-1Q 1024 24 24 17694720 3840×2160 2
Workstations
2560×1600
4
or lower
Maximum Virtual
Frame Maximum
Virtual Intended vGPUs Available Display Displays
Buffer vGPUs
GPU Type Use Case per Pixels Resolution per
(MB) per GPU
Board vGPU
5120×2880 1
4096×2160 2
Virtual
A10-2B 2048 12 12 17694720 3840×2160 2
Desktops
2560×1600
4
or lower
Maximum Virtual
Frame Maximum
Virtual Intended vGPUs Available Display Displays
Buffer vGPUs
GPU Type Use Case per Pixels Resolution per
(MB) per GPU
Board vGPU
5120×2880 1
4096×2160 1
Virtual
A10-1B 1024 24 24 16384000 3840×2160 1
Desktops
2560×1600 5
4
or lower
Virtual
Frame Maximum Maximum Maximum
Virtual Intended Displays
Buffer vGPUs vGPUs Display
GPU Type Use Case per
(MB) per GPU per Board Resolution
vGPU
Training 2
A10-24C 24576 1 1 4096×2160 1
Workloads
Training 2
A10-12C 12288 2 2 4096×2160 1
Workloads
Training 2
A10-8C 8192 3 3 4096×2160 1
Workloads
Training 2
A10-6C 6144 4 4 4096×2160 1
Workloads
Inference 2
A10-4C 4096 6 6 4096×2160 1
Workloads
Virtual
Frame Maximum Maximum Maximum
Virtual Intended Displays
Buffer vGPUs vGPUs Display
GPU Type Use Case per
(MB) per GPU per Board Resolution
vGPU
Virtual 6 6
A10-24A 24576 1 1 1280×1024 1
Applications
Virtual
Frame Maximum Maximum Maximum
Virtual Intended Displays
Buffer vGPUs vGPUs Display
GPU Type Use Case per
(MB) per GPU per Board Resolution
vGPU
Virtual 6 6
A10-12A 12288 2 2 1280×1024 1
Applications
Virtual 6 6
A10-8A 8192 3 3 1280×1024 1
Applications
Virtual 6 6
A10-6A 6144 4 4 1280×1024 1
Applications
Virtual 6 6
A10-4A 4096 6 6 1280×1024 1
Applications
Virtual 6 6
A10-3A 3072 8 8 1280×1024 1
Applications
Virtual 6 6
A10-2A 2048 12 12 1280×1024 1
Applications
Virtual 6 6
A10-1A 1024 24 24 1280×1024 1
Applications
Maximum Virtual
Frame Maximum
Virtual Intended vGPUs Available Display Displays
Buffer vGPUs
GPU Type Use Case per Pixels Resolution per
(MB) per GPU
Board vGPU
7680×4320 2
Virtual
RTXA6000-48Q 49152 1 1 66355200 5120×2880
Workstations 4
or lower
Maximum Virtual
Frame Maximum
Virtual Intended vGPUs Available Display Displays
Buffer vGPUs
GPU Type Use Case per Pixels Resolution per
(MB) per GPU
Board vGPU
7680×4320 2
Virtual
RTXA6000-24Q 24576 2 2 66355200 5120×2880
Workstations 4
or lower
7680×4320 2
Virtual
RTXA6000-16Q 16384 3 3 66355200 5120×2880
Workstations 4
or lower
7680×4320 2
Virtual
RTXA6000-12Q 12288 4 4 66355200 5120×2880
Workstations 4
or lower
7680×4320 2
Virtual
RTXA6000-8Q 8192 6 6 66355200 5120×2880
Workstations 4
or lower
7680×4320 1
Virtual
RTXA6000-6Q 6144 8 8 58982400 5120×2880
Workstations 4
or lower
7680×4320 1
Virtual
RTXA6000-4Q 4096 12 12 58982400 5120×2880
Workstations 4
or lower
7680×4320 1
Virtual 5120×2880 2
RTXA6000-3Q 3072 16 16 35389440
Workstations 4096×2160
4
or lower
7680×4320 1
Virtual 5120×2880 2
RTXA6000-2Q 2048 24 24 35389440
Workstations 4096×2160
4
or lower
5120×2880 1
4096×2160 2
Virtual 8
RTXA6000-1Q 1024 32 32 17694720 3840×2160 2
Workstations
2560×1600
4
or lower
8
The maximum vGPUs per GPU is limited to 32.
Maximum Virtual
Frame Maximum
Virtual Intended vGPUs Available Display Displays
Buffer vGPUs
GPU Type Use Case per Pixels Resolution per
(MB) per GPU
Board vGPU
5120×2880 1
4096×2160 2
Virtual
RTXA6000-2B 2048 24 24 17694720 3840×2160 2
Desktops
2560×1600
4
or lower
5120×2880 1
4096×2160 1
Virtual
RTXA6000-1B 1024 32 32 16384000 3840×2160 1
Desktops
2560×1600 5
4
or lower
Virtual
Frame Maximum Maximum Maximum
Virtual Intended Displays
Buffer vGPUs vGPUs Display
GPU Type Use Case per
(MB) per GPU per Board Resolution
vGPU
Training 2
RTXA6000-48C 49152 1 1 4096×2160 1
Workloads
Training 2
RTXA6000-24C 24576 2 2 4096×2160 1
Workloads
Virtual
Frame Maximum Maximum Maximum
Virtual Intended Displays
Buffer vGPUs vGPUs Display
GPU Type Use Case per
(MB) per GPU per Board Resolution
vGPU
Training 2
RTXA6000-16C 16384 3 3 4096×2160 1
Workloads
Training 2
RTXA6000-12C 12288 4 4 4096×2160 1
Workloads
Training 2
RTXA6000-8C 8192 6 6 4096×2160 1
Workloads
Training 2
RTXA6000-6C 6144 8 8 4096×2160 1
Workloads
Inference 3 2
RTXA6000-4C 4096 12 12 4096×2160 1
Workloads
Virtual
Frame Maximum Maximum Maximum
Virtual Intended Displays
Buffer vGPUs vGPUs Display
GPU Type Use Case per
(MB) per GPU per Board Resolution
vGPU
Virtual 6 6
RTXA6000-48A 49152 1 1 1280×1024 1
Applications
Virtual 6 6
RTXA6000-24A 24576 2 2 1280×1024 1
Applications
Virtual 6 6
RTXA6000-16A 16384 3 3 1280×1024 1
Applications
Virtual 6 6
RTXA6000-12A 12288 4 4 1280×1024 1
Applications
Virtual 6 6
RTXA6000-8A 8192 6 6 1280×1024 1
Applications
Virtual 6 6
RTXA6000-6A 6144 8 8 1280×1024 1
Applications
Virtual 6 6
RTXA6000-4A 4096 12 12 1280×1024 1
Applications
Virtual 6 6
RTXA6000-3A 3072 16 16 1280×1024 1
Applications
Virtual
Frame Maximum Maximum Maximum
Virtual Intended Displays
Buffer vGPUs vGPUs Display
GPU Type Use Case per
(MB) per GPU per Board Resolution
vGPU
Virtual 6 6
RTXA6000-2A 2048 24 24 1280×1024 1
Applications
Virtual 8 6 6
RTXA6000-1A 1024 32 32 1280×1024 1
Applications
Maximum Virtual
Frame Maximum
Virtual Intended vGPUs Available Display Displays
Buffer vGPUs
GPU Type Use Case per Pixels Resolution per
(MB) per GPU
Board vGPU
7680×4320 2
Virtual
RTXA5000-24Q 24576 1 1 66355200 5120×2880
Workstations 4
or lower
7680×4320 2
Virtual
RTXA5000-12Q 12288 2 2 66355200 5120×2880
Workstations 4
or lower
7680×4320 2
Virtual
RTXA5000-8Q 8192 3 3 66355200 5120×2880
Workstations 4
or lower
7680×4320 1
Virtual
RTXA5000-6Q 6144 4 4 58982400 5120×2880
Workstations 4
or lower
Maximum Virtual
Frame Maximum
Virtual Intended vGPUs Available Display Displays
Buffer vGPUs
GPU Type Use Case per Pixels Resolution per
(MB) per GPU
Board vGPU
7680×4320 1
Virtual
RTXA5000-4Q 4096 6 6 58982400 5120×2880
Workstations 4
or lower
7680×4320 1
Virtual 5120×2880 2
RTXA5000-3Q 3072 8 8 35389440
Workstations 4096×2160
4
or lower
7680×4320 1
Virtual 5120×2880 2
RTXA5000-2Q 2048 12 12 35389440
Workstations 4096×2160
4
or lower
5120×2880 1
4096×2160 2
Virtual
RTXA5000-1Q 1024 24 24 17694720 3840×2160 2
Workstations
2560×1600
4
or lower
Maximum Virtual
Frame Maximum
Virtual Intended vGPUs Available Display Displays
Buffer vGPUs
GPU Type Use Case per Pixels Resolution per
(MB) per GPU
Board vGPU
5120×2880 1
Virtual
RTXA5000-2B 2048 12 12 17694720 4096×2160 2
Desktops
3840×2160 2
Maximum Virtual
Frame Maximum
Virtual Intended vGPUs Available Display Displays
Buffer vGPUs
GPU Type Use Case per Pixels Resolution per
(MB) per GPU
Board vGPU
2560×1600
4
or lower
5120×2880 1
4096×2160 1
Virtual
RTXA5000-1B 1024 24 24 16384000 3840×2160 1
Desktops
2560×1600 5
4
or lower
Virtual
Frame Maximum Maximum Maximum
Virtual Intended Displays
Buffer vGPUs vGPUs Display
GPU Type Use Case per
(MB) per GPU per Board Resolution
vGPU
Training 2
RTXA5000-24C 24576 1 1 4096×2160 1
Workloads
Training 2
RTXA5000-12C 12288 2 2 4096×2160 1
Workloads
Training 2
RTXA5000-8C 8192 3 3 4096×2160 1
Workloads
Training 2
RTXA5000-6C 6144 4 4 4096×2160 1
Workloads
Inference 2
RTXA5000-4C 4096 6 6 4096×2160 1
Workloads
Virtual
Frame Maximum Maximum Maximum
Virtual Intended Displays
Buffer vGPUs vGPUs Display
GPU Type Use Case per
(MB) per GPU per Board Resolution
vGPU
Virtual 6 6
RTXA5000-24A 24576 1 1 1280×1024 1
Applications
Virtual 6 6
RTXA5000-12A 12288 2 2 1280×1024 1
Applications
Virtual 6 6
RTXA5000-8A 8192 3 3 1280×1024 1
Applications
Virtual 6 6
RTXA5000-6A 6144 4 4 1280×1024 1
Applications
Virtual 6 6
RTXA5000-4A 4096 6 6 1280×1024 1
Applications
Virtual 6 6
RTXA5000-3A 3072 8 8 1280×1024 1
Applications
Virtual 6 6
RTXA5000-2A 2048 12 12 1280×1024 1
Applications
Virtual 6 6
RTXA5000-1A 1024 24 24 1280×1024 1
Applications
Maximum Virtual
Frame Maximum
Virtual Intended vGPUs Available Display Displays
Buffer vGPUs
GPU Type Use Case per Pixels Resolution per
(MB) per GPU
Board vGPU
Virtual
M60-8Q 8192 1 2 35389440 5120×2880 2
Workstations
Maximum Virtual
Frame Maximum
Virtual Intended vGPUs Available Display Displays
Buffer vGPUs
GPU Type Use Case per Pixels Resolution per
(MB) per GPU
Board vGPU
4096×2160
4
or lower
5120×2880 2
Virtual
M60-4Q 4096 2 4 35389440 4096×2160
Workstations 4
or lower
5120×2880 2
Virtual
M60-2Q 2048 4 8 35389440 4096×2160
Workstations 4
or lower
5120×2880 1
Virtual
4096×2160 2
Desktops,
M60-1Q 1024 8 16 17694720 3840×2160 2
Virtual
Workstations 2560×1600
4
or lower
Virtual
Desktops, 1
M60-0Q 512 16 32 8192000 2560×1600 2
Virtual
Workstations
Maximum Virtual
Frame Maximum
Virtual Intended vGPUs Available Display Displays
Buffer vGPUs
GPU Type Use Case per Pixels Resolution per
(MB) per GPU
Board vGPU
5120×2880 1
Virtual
M60-2B 2048 4 8 17694720 4096×2160 2
Desktops
3840×2160 2
Maximum Virtual
Frame Maximum
Virtual Intended vGPUs Available Display Displays
Buffer vGPUs
GPU Type Use Case per Pixels Resolution per
(MB) per GPU
Board vGPU
2560×1600
4
or lower
5120×2880 1
4096×2160 2
4
Virtual
M60-2B4 2048 4 8 17694720 3840×2160 2
Desktops
2560×1600
4
or lower
5120×2880 1
4096×2160 1
Virtual
M60-1B 1024 8 16 16384000 3840×2160 1
Desktops
2560×1600 5
4
or lower
5120×2880 1
4096×2160 1
4
Virtual
M60-1B4 1024 8 16 16384000 3840×2160 1
Desktops
2560×1600 5
4
or lower
Virtual 1
M60-0B 512 16 32 8192000 2560×1600 2
Desktops
Virtual
Frame Maximum Maximum Maximum
Virtual Intended Displays
Buffer vGPUs vGPUs Display
GPU Type Use Case per
(MB) per GPU per Board Resolution
vGPU
Virtual 6 6
M60-8A 8192 1 2 1280×1024 1
Applications
Virtual 6 6
M60-4A 4096 2 4 1280×1024 1
Applications
Virtual
Frame Maximum Maximum Maximum
Virtual Intended Displays
Buffer vGPUs vGPUs Display
GPU Type Use Case per
(MB) per GPU per Board Resolution
vGPU
Virtual 6 6
M60-2A 2048 4 8 1280×1024 1
Applications
Virtual 6 6
M60-1A 1024 8 16 1280×1024 1
Applications
Maximum Virtual
Frame Maximum
Virtual Intended vGPUs Available Display Displays
Buffer vGPUs
GPU Type Use Case per Pixels Resolution per
(MB) per GPU
Board vGPU
5120×2880 2
Virtual
M10-8Q 8192 1 4 35389440 4096×2160
Workstations 4
or lower
5120×2880 2
Virtual
M10-4Q 4096 2 8 35389440 4096×2160
Workstations 4
or lower
5120×2880 2
Virtual
M10-2Q 2048 4 16 35389440 4096×2160
Workstations 4
or lower
Virtual 5120×2880 1
Desktops,
M10-1Q 1024 8 32 17694720 4096×2160 2
Virtual
Workstations 3840×2160 2
Maximum Virtual
Frame Maximum
Virtual Intended vGPUs Available Display Displays
Buffer vGPUs
GPU Type Use Case per Pixels Resolution per
(MB) per GPU
Board vGPU
2560×1600
4
or lower
Virtual
Desktops, 1
M10-0Q 512 16 64 8192000 2560×1600 2
Virtual
Workstations
Maximum Virtual
Frame Maximum
Virtual Intended vGPUs Available Display Displays
Buffer vGPUs
GPU Type Use Case per Pixels Resolution per
(MB) per GPU
Board vGPU
5120×2880 1
4096×2160 2
Virtual
M10-2B 2048 4 16 17694720 3840×2160 2
Desktops
2560×1600
4
or lower
5120×2880 1
4096×2160 2
4
Virtual
M10-2B4 2048 4 16 17694720 3840×2160 2
Desktops
2560×1600
4
or lower
5120×2880 1
Virtual
M10-1B 1024 8 32 16384000 4096×2160 1
Desktops
3840×2160 1
Maximum Virtual
Frame Maximum
Virtual Intended vGPUs Available Display Displays
Buffer vGPUs
GPU Type Use Case per Pixels Resolution per
(MB) per GPU
Board vGPU
2560×1600 5
4
or lower
5120×2880 1
4096×2160 1
4
Virtual
M10-1B4 1024 8 32 16384000 3840×2160 1
Desktops
2560×1600 5
4
or lower
Virtual 1
M10-0B 512 16 64 8192000 2560×1600 2
Desktops
Virtual
Frame Maximum Maximum Maximum
Virtual Intended Displays
Buffer vGPUs vGPUs Display
GPU Type Use Case per
(MB) per GPU per Board Resolution
vGPU
Virtual 6 6
M10-8A 8192 1 4 1280×1024 1
Applications
Virtual 6 6
M10-4A 4096 2 8 1280×1024 1
Applications
Virtual 6 6
M10-2A 2048 4 16 1280×1024 1
Applications
Virtual 6 6
M10-1A 1024 8 32 1280×1024 1
Applications
using a small number of high resolution displays or a larger number of lower resolution
displays with these vGPU types. The maximum number of displays per vGPU is based
on a configuration in which all displays have the same resolution. For examples of
configurations with a mixture of display resolutions, see Mixed Display Configurations for
B-Series and Q-Series vGPUs.
Maximum Virtual
Frame Maximum
Virtual Intended vGPUs Available Display Displays
Buffer vGPUs
GPU Type Use Case per Pixels Resolution per
(MB) per GPU
Board vGPU
5120×2880 2
Virtual
M6-8Q 8192 1 1 35389440 4096×2160
Workstations 4
or lower
5120×2880 2
Virtual
M6-4Q 4096 2 2 35389440 4096×2160
Workstations 4
or lower
5120×2880 2
Virtual
M6-2Q 2048 4 4 35389440 4096×2160
Workstations 4
or lower
5120×2880 1
Virtual
4096×2160 2
Desktops,
M6-1Q 1024 8 8 17694720 3840×2160 2
Virtual
Workstations 2560×1600
4
or lower
Virtual
Desktops, 1
M6-0Q 512 16 16 8192000 2560×1600 2
Virtual
Workstations
Maximum Virtual
Frame Maximum
Virtual Intended vGPUs Available Display Displays
Buffer vGPUs
GPU Type Use Case per Pixels Resolution per
(MB) per GPU
Board vGPU
5120×2880 1
4096×2160 2
Virtual
M6-2B 2048 4 4 17694720 3840×2160 2
Desktops
2560×1600
4
or lower
5120×2880 1
4096×2160 2
4
Virtual
M6-2B4 2048 4 4 17694720 3840×2160 2
Desktops
2560×1600
4
or lower
5120×2880 1
4096×2160 1
Virtual
M6-1B 1024 8 8 16384000 3840×2160 1
Desktops
2560×1600 5
4
or lower
5120×2880 1
4096×2160 1
4
Virtual
M6-1B4 1024 8 8 16384000 3840×2160 1
Desktops
2560×1600 5
4
or lower
Virtual 1
M6-0B 512 16 16 8192000 2560×1600 2
Desktops
Virtual
Frame Maximum Maximum Maximum
Virtual Intended Displays
Buffer vGPUs vGPUs Display
GPU Type Use Case per
(MB) per GPU per Board Resolution
vGPU
Virtual 6 6
M6-8A 8192 1 1 1280×1024 1
Applications
Virtual
Frame Maximum Maximum Maximum
Virtual Intended Displays
Buffer vGPUs vGPUs Display
GPU Type Use Case per
(MB) per GPU per Board Resolution
vGPU
Virtual 6 6
M6-4A 4096 2 2 1280×1024 1
Applications
Virtual 6 6
M6-2A 2048 4 4 1280×1024 1
Applications
Virtual 6 6
M6-1A 1024 8 8 1280×1024 1
Applications
Maximum Virtual
Frame Maximum
Virtual Intended vGPUs Available Display Displays
Buffer vGPUs
GPU Type Use Case per Pixels Resolution per
(MB) per GPU
Board vGPU
7680×4320 2
Virtual
P100C-12Q 12288 1 1 66355200 5120×2880
Workstations 4
or lower
7680×4320 1
Virtual
P100C-6Q 6144 2 2 58982400 5120×2880
Workstations 4
or lower
7680×4320 1
Virtual
P100C-4Q 4096 3 3 58982400 5120×2880
Workstations 4
or lower
Virtual 7680×4320 1
P100C-2Q 2048 6 6 35389440
Workstations 5120×2880 2
Maximum Virtual
Frame Maximum
Virtual Intended vGPUs Available Display Displays
Buffer vGPUs
GPU Type Use Case per Pixels Resolution per
(MB) per GPU
Board vGPU
4096×2160
4
or lower
5120×2880 1
Virtual
4096×2160 2
Desktops,
P100C-1Q 1024 12 12 17694720 3840×2160 2
Virtual
Workstations 2560×1600
4
or lower
Maximum Virtual
Frame Maximum
Virtual Intended vGPUs Available Display Displays
Buffer vGPUs
GPU Type Use Case per Pixels Resolution per
(MB) per GPU
Board vGPU
5120×2880 1
4096×2160 2
Virtual
P100C-2B 2048 6 6 17694720 3840×2160 2
Desktops
2560×1600
4
or lower
5120×2880 1
4096×2160 2
4
Virtual
P100C-2B4 2048 6 6 17694720 3840×2160 2
Desktops
2560×1600
4
or lower
Virtual 5120×2880 1
P100C-1B 1024 12 12 16384000
Desktops 4096×2160 1
Maximum Virtual
Frame Maximum
Virtual Intended vGPUs Available Display Displays
Buffer vGPUs
GPU Type Use Case per Pixels Resolution per
(MB) per GPU
Board vGPU
3840×2160 1
2560×1600 5
4
or lower
5120×2880 1
4096×2160 1
4
Virtual
P100C-1B4 1024 12 12 16384000 3840×2160 1
Desktops
2560×1600 5
4
or lower
Virtual
Frame Maximum Maximum Maximum
Virtual Intended Displays
Buffer vGPUs vGPUs Display
GPU Type Use Case per
(MB) per GPU per Board Resolution
vGPU
Training 2
P100C-12C 12288 1 1 4096×2160 1
Workloads
Training 2
P100C-6C 6144 2 2 4096×2160 1
Workloads
Inference 2
P100C-4C 4096 3 3 4096×2160 1
Workloads
Virtual
Frame Maximum Maximum Maximum
Virtual Intended Displays
Buffer vGPUs vGPUs Display
GPU Type Use Case per
(MB) per GPU per Board Resolution
vGPU
Virtual 6 6
P100C-12A 12288 1 1 1280×1024 1
Applications
Virtual
Frame Maximum Maximum Maximum
Virtual Intended Displays
Buffer vGPUs vGPUs Display
GPU Type Use Case per
(MB) per GPU per Board Resolution
vGPU
Virtual 6 6
P100C-6A 6144 2 2 1280×1024 1
Applications
Virtual 6 6
P100C-4A 4096 3 3 1280×1024 1
Applications
Virtual 6 6
P100C-2A 2048 6 6 1280×1024 1
Applications
Virtual 6 6
P100C-1A 1024 12 12 1280×1024 1
Applications
Maximum Virtual
Frame Maximum
Virtual Intended vGPUs Available Display Displays
Buffer vGPUs
GPU Type Use Case per Pixels Resolution per
(MB) per GPU
Board vGPU
7680×4320 2
Virtual
P100-16Q 16384 1 1 66355200 5120×2880
Workstations 4
or lower
7680×4320 2
Virtual
P100-8Q 8192 2 2 66355200 5120×2880
Workstations 4
or lower
7680×4320 1
Virtual
P100-4Q 4096 4 4 58982400 5120×2880
Workstations 4
or lower
Maximum Virtual
Frame Maximum
Virtual Intended vGPUs Available Display Displays
Buffer vGPUs
GPU Type Use Case per Pixels Resolution per
(MB) per GPU
Board vGPU
7680×4320 1
Virtual 5120×2880 2
P100-2Q 2048 8 8 35389440
Workstations 4096×2160
4
or lower
5120×2880 1
Virtual
4096×2160 2
Desktops,
P100-1Q 1024 16 16 17694720 3840×2160 2
Virtual
Workstations 2560×1600
4
or lower
Maximum Virtual
Frame Maximum
Virtual Intended vGPUs Available Display Displays
Buffer vGPUs
GPU Type Use Case per Pixels Resolution per
(MB) per GPU
Board vGPU
5120×2880 1
4096×2160 2
Virtual
P100-2B 2048 8 8 17694720 3840×2160 2
Desktops
2560×1600
4
or lower
5120×2880 1
4096×2160 2
4
Virtual
P100-2B4 2048 8 8 17694720 3840×2160 2
Desktops
2560×1600
4
or lower
Maximum Virtual
Frame Maximum
Virtual Intended vGPUs Available Display Displays
Buffer vGPUs
GPU Type Use Case per Pixels Resolution per
(MB) per GPU
Board vGPU
5120×2880 1
4096×2160 1
Virtual
P100-1B 1024 16 16 16384000 3840×2160 1
Desktops
2560×1600 5
4
or lower
5120×2880 1
4096×2160 1
4
Virtual
P100-1B4 1024 16 16 16384000 3840×2160 1
Desktops
2560×1600 5
4
or lower
Virtual
Frame Maximum Maximum Maximum
Virtual Intended Displays
Buffer vGPUs vGPUs Display
GPU Type Use Case per
(MB) per GPU per Board Resolution
vGPU
Training 2
P100-16C 16384 1 1 4096×2160 1
Workloads
Training 2
P100-8C 8192 2 2 4096×2160 1
Workloads
Inference 2
P100-4C 4096 4 4 4096×2160 1
Workloads
Virtual
Frame Maximum Maximum Maximum
Virtual Intended Displays
Buffer vGPUs vGPUs Display
GPU Type Use Case per
(MB) per GPU per Board Resolution
vGPU
Virtual 6 6
P100-16A 16384 1 1 1280×1024 1
Applications
Virtual 6 6
P100-8A 8192 2 2 1280×1024 1
Applications
Virtual 6 6
P100-4A 4096 4 4 1280×1024 1
Applications
Virtual 6 6
P100-2A 2048 8 8 1280×1024 1
Applications
Virtual 6 6
P100-1A 1024 16 16 1280×1024 1
Applications
Maximum Virtual
Frame Maximum
Virtual Intended vGPUs Available Display Displays
Buffer vGPUs
GPU Type Use Case per Pixels Resolution per
(MB) per GPU
Board vGPU
7680×4320 2
Virtual
P100X-16Q 16384 1 1 66355200 5120×2880
Workstations 4
or lower
7680×4320 2
Virtual
P100X-8Q 8192 2 2 66355200 5120×2880
Workstations 4
or lower
Maximum Virtual
Frame Maximum
Virtual Intended vGPUs Available Display Displays
Buffer vGPUs
GPU Type Use Case per Pixels Resolution per
(MB) per GPU
Board vGPU
7680×4320 1
Virtual
P100X-4Q 4096 4 4 58982400 5120×2880
Workstations 4
or lower
7680×4320 1
Virtual 5120×2880 2
P100X-2Q 2048 8 8 35389440
Workstations 4096×2160
4
or lower
5120×2880 1
Virtual
4096×2160 2
Desktops,
P100X-1Q 1024 16 16 17694720 3840×2160 2
Virtual
Workstations 2560×1600
4
or lower
Maximum Virtual
Frame Maximum
Virtual Intended vGPUs Available Display Displays
Buffer vGPUs
GPU Type Use Case per Pixels Resolution per
(MB) per GPU
Board vGPU
5120×2880 1
4096×2160 2
Virtual
P100X-2B 2048 8 8 17694720 3840×2160 2
Desktops
2560×1600
4
or lower
Virtual 5120×2880 1
4 2048 8 8 17694720
P100X-2B4
Desktops 4096×2160 2
Maximum Virtual
Frame Maximum
Virtual Intended vGPUs Available Display Displays
Buffer vGPUs
GPU Type Use Case per Pixels Resolution per
(MB) per GPU
Board vGPU
3840×2160 2
2560×1600
4
or lower
5120×2880 1
4096×2160 1
Virtual
P100X-1B 1024 16 16 16384000 3840×2160 1
Desktops
2560×1600 5
4
or lower
5120×2880 1
4096×2160 1
4
Virtual
P100X-1B4 1024 16 16 16384000 3840×2160 1
Desktops
2560×1600 5
4
or lower
Virtual
Frame Maximum Maximum Maximum
Virtual Intended Displays
Buffer vGPUs vGPUs Display
GPU Type Use Case per
(MB) per GPU per Board Resolution
vGPU
Training 2
P100X-16C 16384 1 1 4096×2160 1
Workloads
Training 2
P100X-8C 8192 2 2 4096×2160 1
Workloads
Inference 2
P100X-4C 4096 4 4 4096×2160 1
Workloads
Virtual
Frame Maximum Maximum Maximum
Virtual Intended Displays
Buffer vGPUs vGPUs Display
GPU Type Use Case per
(MB) per GPU per Board Resolution
vGPU
Virtual 6 6
P100X-16A 16384 1 1 1280×1024 1
Applications
Virtual 6 6
P100X-8A 8192 2 2 1280×1024 1
Applications
Virtual 6 6
P100X-4A 4096 4 4 1280×1024 1
Applications
Virtual 6 6
P100X-2A 2048 8 8 1280×1024 1
Applications
Virtual 6 6
P100X-1A 1024 16 16 1280×1024 1
Applications
Maximum Virtual
Frame Maximum
Virtual Intended vGPUs Available Display Displays
Buffer vGPUs
GPU Type Use Case per Pixels Resolution per
(MB) per GPU
Board vGPU
7680×4320 2
Virtual
P40-24Q 24576 1 1 66355200 5120×2880
Workstations 4
or lower
7680×4320 2
Virtual
P40-12Q 12288 2 2 66355200 5120×2880
Workstations 4
or lower
Maximum Virtual
Frame Maximum
Virtual Intended vGPUs Available Display Displays
Buffer vGPUs
GPU Type Use Case per Pixels Resolution per
(MB) per GPU
Board vGPU
7680×4320 2
Virtual
P40-8Q 8192 3 3 66355200 5120×2880
Workstations 4
or lower
7680×4320 1
Virtual
P40-6Q 6144 4 4 58982400 5120×2880
Workstations 4
or lower
7680×4320 1
Virtual
P40-4Q 4096 6 6 58982400 5120×2880
Workstations 4
or lower
7680×4320 1
Virtual 5120×2880 2
P40-3Q 3072 8 8 35389440
Workstations 4096×2160
4
or lower
7680×4320 1
Virtual 5120×2880 2
P40-2Q 2048 12 12 35389440
Workstations 4096×2160
4
or lower
5120×2880 1
Virtual
4096×2160 2
Desktops,
P40-1Q 1024 24 24 17694720 3840×2160 2
Virtual
Workstations 2560×1600
4
or lower
Maximum Virtual
Frame Maximum
Virtual Intended vGPUs Available Display Displays
Buffer vGPUs
GPU Type Use Case per Pixels Resolution per
(MB) per GPU
Board vGPU
5120×2880 1
4096×2160 2
Virtual
P40-2B 2048 12 12 17694720 3840×2160 2
Desktops
2560×1600
4
or lower
5120×2880 1
4096×2160 2
4
Virtual
P40-2B4 2048 12 12 17694720 3840×2160 2
Desktops
2560×1600
4
or lower
5120×2880 1
4096×2160 1
Virtual
P40-1B 1024 24 24 16384000 3840×2160 1
Desktops
2560×1600 5
4
or lower
5120×2880 1
4096×2160 1
4
Virtual
P40-1B4 1024 24 24 16384000 3840×2160 1
Desktops
2560×1600 5
4
or lower
Virtual
Frame Maximum Maximum Maximum
Virtual Intended Displays
Buffer vGPUs vGPUs Display
GPU Type Use Case per
(MB) per GPU per Board Resolution
vGPU
Training 2
P40-24C 24576 1 1 4096×2160 1
Workloads
Training 2
P40-12C 12288 2 2 4096×2160 1
Workloads
Virtual
Frame Maximum Maximum Maximum
Virtual Intended Displays
Buffer vGPUs vGPUs Display
GPU Type Use Case per
(MB) per GPU per Board Resolution
vGPU
Training 2
P40-8C 8192 3 3 4096×2160 1
Workloads
Training 2
P40-6C 6144 4 4 4096×2160 1
Workloads
Inference 2
P40-4C 4096 6 6 4096×2160 1
Workloads
Virtual
Frame Maximum Maximum Maximum
Virtual Intended Displays
Buffer vGPUs vGPUs Display
GPU Type Use Case per
(MB) per GPU per Board Resolution
vGPU
Virtual 6 6
P40-24A 24576 1 1 1280×1024 1
Applications
Virtual 6 6
P40-12A 12288 2 2 1280×1024 1
Applications
Virtual 6 6
P40-8A 8192 3 3 1280×1024 1
Applications
Virtual 6 6
P40-6A 6144 4 4 1280×1024 1
Applications
Virtual 6 6
P40-4A 4096 6 6 1280×1024 1
Applications
Virtual 6 6
P40-3A 3072 8 8 1280×1024 1
Applications
Virtual 6 6
P40-2A 2048 12 12 1280×1024 1
Applications
Virtual 6 6
P40-1A 1024 24 24 1280×1024 1
Applications
Maximum Virtual
Frame Maximum
Virtual Intended vGPUs Available Display Displays
Buffer vGPUs
GPU Type Use Case per Pixels Resolution per
(MB) per GPU
Board vGPU
7680×4320 2
Virtual
P6-16Q 16384 1 1 66355200 5120×2880
Workstations 4
or lower
7680×4320 2
Virtual
P6-8Q 8192 2 2 66355200 5120×2880
Workstations 4
or lower
7680×4320 1
Virtual
P6-4Q 4096 4 4 58982400 5120×2880
Workstations 4
or lower
7680×4320 1
Virtual 5120×2880 2
P6-2Q 2048 8 8 35389440
Workstations 4096×2160
4
or lower
5120×2880 1
Virtual
4096×2160 2
Desktops,
P6-1Q 1024 16 16 17694720 3840×2160 2
Virtual
Workstations 2560×1600
4
or lower
using a small number of high resolution displays or a larger number of lower resolution
displays with these vGPU types. The maximum number of displays per vGPU is based
on a configuration in which all displays have the same resolution. For examples of
configurations with a mixture of display resolutions, see Mixed Display Configurations for
B-Series and Q-Series vGPUs.
Maximum Virtual
Frame Maximum
Virtual Intended vGPUs Available Display Displays
Buffer vGPUs
GPU Type Use Case per Pixels Resolution per
(MB) per GPU
Board vGPU
5120×2880 1
4096×2160 2
Virtual
P6-2B 2048 8 8 17694720 3840×2160 2
Desktops
2560×1600
4
or lower
5120×2880 1
4096×2160 2
4
Virtual
P6-2B4 2048 8 8 17694720 3840×2160 2
Desktops
2560×1600
4
or lower
5120×2880 1
4096×2160 1
Virtual
P6-1B 1024 16 16 16384000 3840×2160 1
Desktops
2560×1600 5
4
or lower
5120×2880 1
4096×2160 1
4
Virtual
P6-1B4 1024 16 16 16384000 3840×2160 1
Desktops
2560×1600 5
4
or lower
Virtual
Frame Maximum Maximum Maximum
Virtual Intended Displays
Buffer vGPUs vGPUs Display
GPU Type Use Case per
(MB) per GPU per Board Resolution
vGPU
Training 2
P6-16C 16384 1 1 4096×2160 1
Workloads
Training 2
P6-8C 8192 2 2 4096×2160 1
Workloads
Inference 2
P6-4C 4096 4 4 4096×2160 1
Workloads
Virtual
Frame Maximum Maximum Maximum
Virtual Intended Displays
Buffer vGPUs vGPUs Display
GPU Type Use Case per
(MB) per GPU per Board Resolution
vGPU
Virtual 6 6
P6-16A 16384 1 1 1280×1024 1
Applications
Virtual 6 6
P6-8A 8192 2 2 1280×1024 1
Applications
Virtual 6 6
P6-4A 4096 4 4 1280×1024 1
Applications
Virtual 6 6
P6-2A 2048 8 8 1280×1024 1
Applications
Virtual 6 6
P6-1A 1024 16 16 1280×1024 1
Applications
on a configuration in which all displays have the same resolution. For examples of
configurations with a mixture of display resolutions, see Mixed Display Configurations for
B-Series and Q-Series vGPUs.
Maximum Virtual
Frame Maximum
Virtual Intended vGPUs Available Display Displays
Buffer vGPUs
GPU Type Use Case per Pixels Resolution per
(MB) per GPU
Board vGPU
7680×4320 2
Virtual
P4-8Q 8192 1 1 66355200 5120×2880
Workstations 4
or lower
7680×4320 1
Virtual
P4-4Q 4096 2 2 58982400 5120×2880
Workstations 4
or lower
7680×4320 1
Virtual 5120×2880 2
P4-2Q 2048 4 4 35389440
Workstations 4096×2160
4
or lower
5120×2880 1
Virtual
4096×2160 2
Desktops,
P4-1Q 1024 8 8 17694720 3840×2160 2
Virtual
Workstations 2560×1600
4
or lower
Maximum Virtual
Frame Maximum
Virtual Intended vGPUs Available Display Displays
Buffer vGPUs
GPU Type Use Case per Pixels Resolution per
(MB) per GPU
Board vGPU
Virtual
P4-2B 2048 4 4 17694720 5120×2880 1
Desktops
Maximum Virtual
Frame Maximum
Virtual Intended vGPUs Available Display Displays
Buffer vGPUs
GPU Type Use Case per Pixels Resolution per
(MB) per GPU
Board vGPU
4096×2160 2
3840×2160 2
2560×1600
4
or lower
5120×2880 1
4096×2160 2
4
Virtual
P4-2B4 2048 4 4 17694720 3840×2160 2
Desktops
2560×1600
4
or lower
5120×2880 1
4096×2160 1
Virtual
P4-1B 1024 8 8 16384000 3840×2160 1
Desktops
2560×1600 5
4
or lower
5120×2880 1
4096×2160 1
4
Virtual
P4-1B4 1024 8 8 16384000 3840×2160 1
Desktops
2560×1600 5
4
or lower
Virtual
Frame Maximum Maximum Maximum
Virtual Intended Displays
Buffer vGPUs vGPUs Display
GPU Type Use Case per
(MB) per GPU per Board Resolution
vGPU
Training 2
P4-8C 8192 1 1 4096×2160 1
Workloads
Inference 2
P4-4C 4096 2 2 4096×2160 1
Workloads
Virtual
Frame Maximum Maximum Maximum
Virtual Intended Displays
Buffer vGPUs vGPUs Display
GPU Type Use Case per
(MB) per GPU per Board Resolution
vGPU
Virtual 6 6
P4-8A 8192 1 1 1280×1024 1
Applications
Virtual 6 6
P4-4A 4096 2 2 1280×1024 1
Applications
Virtual 6 6
P4-2A 2048 4 4 1280×1024 1
Applications
Virtual 6 6
P4-1A 1024 8 8 1280×1024 1
Applications
Maximum Virtual
Frame Maximum
Virtual Intended vGPUs Available Display Displays
Buffer vGPUs
GPU Type Use Case per Pixels Resolution per
(MB) per GPU
Board vGPU
7680×4320 2
Virtual
T4-16Q 16384 1 1 66355200 5120×2880
Workstations 4
or lower
Virtual
T4-8Q 8192 2 2 66355200 7680×4320 2
Workstations
Maximum Virtual
Frame Maximum
Virtual Intended vGPUs Available Display Displays
Buffer vGPUs
GPU Type Use Case per Pixels Resolution per
(MB) per GPU
Board vGPU
5120×2880
4
or lower
7680×4320 1
Virtual
T4-4Q 4096 4 4 58982400 5120×2880
Workstations 4
or lower
7680×4320 1
Virtual 5120×2880 2
T4-2Q 2048 8 8 35389440
Workstations 4096×2160
4
or lower
5120×2880 1
Virtual
4096×2160 2
Desktops,
T4-1Q 1024 16 16 17694720 3840×2160 2
Virtual
Workstations 2560×1600
4
or lower
Maximum Virtual
Frame Maximum
Virtual Intended vGPUs Available Display Displays
Buffer vGPUs
GPU Type Use Case per Pixels Resolution per
(MB) per GPU
Board vGPU
5120×2880 1
4096×2160 2
Virtual
T4-2B 2048 8 8 17694720 3840×2160 2
Desktops
2560×1600
4
or lower
Maximum Virtual
Frame Maximum
Virtual Intended vGPUs Available Display Displays
Buffer vGPUs
GPU Type Use Case per Pixels Resolution per
(MB) per GPU
Board vGPU
5120×2880 1
4096×2160 2
4
Virtual
T4-2B4 2048 8 8 17694720 3840×2160 2
Desktops
2560×1600
4
or lower
5120×2880 1
4096×2160 1
Virtual
T4-1B 1024 16 16 16384000 3840×2160 1
Desktops
2560×1600 5
4
or lower
5120×2880 1
4096×2160 1
4
Virtual
T4-1B4 1024 16 16 16384000 3840×2160 1
Desktops
2560×1600 5
4
or lower
Virtual
Frame Maximum Maximum Maximum
Virtual Intended Displays
Buffer vGPUs vGPUs Display
GPU Type Use Case per
(MB) per GPU per Board Resolution
vGPU
Training 2
T4-16C 16384 1 1 4096×2160 1
Workloads
Training 2
T4-8C 8192 2 2 4096×2160 1
Workloads
Inference 2
T4-4C 4096 4 4 4096×2160 1
Workloads
These vGPU types support a single display with a fixed maximum resolution.
Virtual
Frame Maximum Maximum Maximum
Virtual Intended Displays
Buffer vGPUs vGPUs Display
GPU Type Use Case per
(MB) per GPU per Board Resolution
vGPU
Virtual 6 6
T4-16A 16384 1 1 1280×1024 1
Applications
Virtual 6 6
T4-8A 8192 2 2 1280×1024 1
Applications
Virtual 6 6
T4-4A 4096 4 4 1280×1024 1
Applications
Virtual 6 6
T4-2A 2048 8 8 1280×1024 1
Applications
Virtual 6 6
T4-1A 1024 16 16 1280×1024 1
Applications
Maximum Virtual
Frame Maximum
Virtual Intended vGPUs Available Display Displays
Buffer vGPUs
GPU Type Use Case per Pixels Resolution per
(MB) per GPU
Board vGPU
7680×4320 2
Virtual
V100X-16Q 16384 1 1 66355200 5120×2880
Workstations 4
or lower
7680×4320 2
Virtual
V100X-8Q 8192 2 2 66355200 5120×2880
Workstations 4
or lower
Maximum Virtual
Frame Maximum
Virtual Intended vGPUs Available Display Displays
Buffer vGPUs
GPU Type Use Case per Pixels Resolution per
(MB) per GPU
Board vGPU
7680×4320 1
Virtual
V100X-4Q 4096 4 4 58982400 5120×2880
Workstations 4
or lower
7680×4320 1
Virtual 5120×2880 2
V100X-2Q 2048 8 8 35389440
Workstations 4096×2160
4
or lower
5120×2880 1
Virtual
4096×2160 2
Desktops,
V100X-1Q 1024 16 16 17694720 3840×2160 2
Virtual
Workstations 2560×1600
4
or lower
Maximum Virtual
Frame Maximum
Virtual Intended vGPUs Available Display Displays
Buffer vGPUs
GPU Type Use Case per Pixels Resolution per
(MB) per GPU
Board vGPU
5120×2880 1
4096×2160 2
Virtual
V100X-2B 2048 8 8 17694720 3840×2160 2
Desktops
2560×1600
4
or lower
Virtual 5120×2880 1
4 2048 8 8 17694720
V100X-2B4
Desktops 4096×2160 2
Maximum Virtual
Frame Maximum
Virtual Intended vGPUs Available Display Displays
Buffer vGPUs
GPU Type Use Case per Pixels Resolution per
(MB) per GPU
Board vGPU
3840×2160 2
2560×1600
4
or lower
5120×2880 1
4096×2160 1
Virtual
V100X-1B 1024 16 16 16384000 3840×2160 1
Desktops
2560×1600 5
4
or lower
5120×2880 1
4096×2160 1
4
Virtual
V100X-1B4 1024 16 16 16384000 3840×2160 1
Desktops
2560×1600 5
4
or lower
Virtual
Frame Maximum Maximum Maximum
Virtual Intended Displays
Buffer vGPUs vGPUs Display
GPU Type Use Case per
(MB) per GPU per Board Resolution
vGPU
Training 2
V100X-16C 16384 1 1 4096×2160 1
Workloads
Training 2
V100X-8C 8192 2 2 4096×2160 1
Workloads
Inference 2
V100X-4C 4096 4 4 4096×2160 1
Workloads
Virtual
Frame Maximum Maximum Maximum
Virtual Intended Displays
Buffer vGPUs vGPUs Display
GPU Type Use Case per
(MB) per GPU per Board Resolution
vGPU
Virtual 6 6
V100X-16A 16384 1 1 1280×1024 1
Applications
Virtual 6 6
V100X-8A 8192 2 2 1280×1024 1
Applications
Virtual 6 6
V100X-4A 4096 4 4 1280×1024 1
Applications
Virtual 6 6
V100X-2A 2048 8 8 1280×1024 1
Applications
Virtual 6 6
V100X-1A 1024 16 16 1280×1024 1
Applications
Maximum Virtual
Frame Maximum
Virtual Intended vGPUs Available Display Displays
Buffer vGPUs
GPU Type Use Case per Pixels Resolution per
(MB) per GPU
Board vGPU
7680×4320 2
Virtual
V100DX-32Q 32768 1 1 66355200 5120×2880
Workstations 4
or lower
7680×4320 2
Virtual
V100DX-16Q 16384 2 2 66355200 5120×2880
Workstations 4
or lower
Maximum Virtual
Frame Maximum
Virtual Intended vGPUs Available Display Displays
Buffer vGPUs
GPU Type Use Case per Pixels Resolution per
(MB) per GPU
Board vGPU
7680×4320 2
Virtual
V100DX-8Q 8192 4 4 66355200 5120×2880
Workstations 4
or lower
7680×4320 1
Virtual
V100DX-4Q 4096 8 8 58982400 5120×2880
Workstations 4
or lower
7680×4320 1
Virtual 5120×2880 2
V100DX-2Q 2048 16 16 35389440
Workstations 4096×2160
4
or lower
5120×2880 1
Virtual
4096×2160 2
Desktops,
V100DX-1Q 1024 32 32 17694720 3840×2160 2
Virtual
Workstations 2560×1600
4
or lower
Maximum Virtual
Frame Maximum
Virtual Intended vGPUs Available Display Displays
Buffer vGPUs
GPU Type Use Case per Pixels Resolution per
(MB) per GPU
Board vGPU
5120×2880 1
Virtual
V100DX-2B 2048 16 16 17694720 4096×2160 2
Desktops
3840×2160 2
Maximum Virtual
Frame Maximum
Virtual Intended vGPUs Available Display Displays
Buffer vGPUs
GPU Type Use Case per Pixels Resolution per
(MB) per GPU
Board vGPU
2560×1600
4
or lower
5120×2880 1
4096×2160 2
4
Virtual
V100DX-2B4 2048 16 16 17694720 3840×2160 2
Desktops
2560×1600
4
or lower
5120×2880 1
4096×2160 1
Virtual
V100DX-1B 1024 32 32 16384000 3840×2160 1
Desktops
2560×1600 5
4
or lower
5120×2880 1
4096×2160 1
4
Virtual
V100DX-1B4 1024 32 32 16384000 3840×2160 1
Desktops
2560×1600 5
4
or lower
Virtual
Frame Maximum Maximum Maximum
Virtual Intended Displays
Buffer vGPUs vGPUs Display
GPU Type Use Case per
(MB) per GPU per Board Resolution
vGPU
Training 2
V100DX-32C 32768 1 1 4096×2160 1
Workloads
Training 2
V100DX-16C 16384 2 2 4096×2160 1
Workloads
Training 2
V100DX-8C 8192 4 4 4096×2160 1
Workloads
Virtual
Frame Maximum Maximum Maximum
Virtual Intended Displays
Buffer vGPUs vGPUs Display
GPU Type Use Case per
(MB) per GPU per Board Resolution
vGPU
Inference 2
V100DX-4C 4096 8 8 4096×2160 1
Workloads
Virtual
Frame Maximum Maximum Maximum
Virtual Intended Displays
Buffer vGPUs vGPUs Display
GPU Type Use Case per
(MB) per GPU per Board Resolution
vGPU
Virtual 6 6
V100DX-32A 32768 1 1 1280×1024 1
Applications
Virtual 6 6
V100DX-16A 16384 2 2 1280×1024 1
Applications
Virtual 6 6
V100DX-8A 8192 4 4 1280×1024 1
Applications
Virtual 6 6
V100DX-4A 4096 8 8 1280×1024 1
Applications
Virtual 6 6
V100DX-2A 2048 16 16 1280×1024 1
Applications
Virtual 6 6
V100DX-1A 1024 32 32 1280×1024 1
Applications
configurations with a mixture of display resolutions, see Mixed Display Configurations for
B-Series and Q-Series vGPUs.
Maximum Virtual
Frame Maximum
Virtual Intended vGPUs Available Display Displays
Buffer vGPUs
GPU Type Use Case per Pixels Resolution per
(MB) per GPU
Board vGPU
7680×4320 2
Virtual
V100-16Q 16384 1 1 66355200 5120×2880
Workstations 4
or lower
7680×4320 2
Virtual
V100-8Q 8192 2 2 66355200 5120×2880
Workstations 4
or lower
7680×4320 1
Virtual
V100-4Q 4096 4 4 58982400 5120×2880
Workstations 4
or lower
7680×4320 1
Virtual 5120×2880 2
V100-2Q 2048 8 8 35389440
Workstations 4096×2160
4
or lower
5120×2880 1
Virtual
4096×2160 2
Desktops,
V100-1Q 1024 16 16 17694720 3840×2160 2
Virtual
Workstations 2560×1600
4
or lower
Maximum Virtual
Frame Maximum
Virtual Intended vGPUs Available Display Displays
Buffer vGPUs
GPU Type Use Case per Pixels Resolution per
(MB) per GPU
Board vGPU
5120×2880 1
4096×2160 2
Virtual
V100-2B 2048 8 8 17694720 3840×2160 2
Desktops
2560×1600
4
or lower
5120×2880 1
4096×2160 2
4
Virtual
V100-2B4 2048 8 8 17694720 3840×2160 2
Desktops
2560×1600
4
or lower
5120×2880 1
4096×2160 1
Virtual
V100-1B 1024 16 16 16384000 3840×2160 1
Desktops
2560×1600 5
4
or lower
5120×2880 1
4096×2160 1
4
Virtual
V100-1B4 1024 16 16 16384000 3840×2160 1
Desktops
2560×1600 5
4
or lower
Virtual
Frame Maximum Maximum Maximum
Virtual Intended Displays
Buffer vGPUs vGPUs Display
GPU Type Use Case per
(MB) per GPU per Board Resolution
vGPU
Training 2
V100-16C 16384 1 1 4096×2160 1
Workloads
Training 2
V100-8C 8192 2 2 4096×2160 1
Workloads
Virtual
Frame Maximum Maximum Maximum
Virtual Intended Displays
Buffer vGPUs vGPUs Display
GPU Type Use Case per
(MB) per GPU per Board Resolution
vGPU
Inference 2
V100-4C 4096 4 4 4096×2160 1
Workloads
Virtual
Frame Maximum Maximum Maximum
Virtual Intended Displays
Buffer vGPUs vGPUs Display
GPU Type Use Case per
(MB) per GPU per Board Resolution
vGPU
Virtual 6 6
V100-16A 16384 1 1 1280×1024 1
Applications
Virtual 6 6
V100-8A 8192 2 2 1280×1024 1
Applications
Virtual 6 6
V100-4A 4096 4 4 1280×1024 1
Applications
Virtual 6 6
V100-2A 2048 8 8 1280×1024 1
Applications
Virtual 6 6
V100-1A 1024 16 16 1280×1024 1
Applications
Maximum Virtual
Frame Maximum
Virtual Intended vGPUs Available Display Displays
Buffer vGPUs
GPU Type Use Case per Pixels Resolution per
(MB) per GPU
Board vGPU
7680×4320 2
Virtual
V100D-32Q 32768 1 1 66355200 5120×2880
Workstations 4
or lower
7680×4320 2
Virtual
V100D-16Q 16384 2 2 66355200 5120×2880
Workstations 4
or lower
7680×4320 2
Virtual
V100D-8Q 8192 4 4 66355200 5120×2880
Workstations 4
or lower
7680×4320 1
Virtual
V100D-4Q 4096 8 8 58982400 5120×2880
Workstations 4
or lower
7680×4320 1
Virtual 5120×2880 2
V100D-2Q 2048 16 16 35389440
Workstations 4096×2160
4
or lower
5120×2880 1
Virtual
4096×2160 2
Desktops,
V100D-1Q 1024 32 32 17694720 3840×2160 2
Virtual
Workstations 2560×1600
4
or lower
Maximum Virtual
Frame Maximum
Virtual Intended vGPUs Available Display Displays
Buffer vGPUs
GPU Type Use Case per Pixels Resolution per
(MB) per GPU
Board vGPU
5120×2880 1
4096×2160 2
Virtual
V100D-2B 2048 16 16 17694720 3840×2160 2
Desktops
2560×1600
4
or lower
5120×2880 1
4096×2160 2
4
Virtual
V100D-2B4 2048 16 16 17694720 3840×2160 2
Desktops
2560×1600
4
or lower
5120×2880 1
4096×2160 1
Virtual
V100D-1B 1024 32 32 16384000 3840×2160 1
Desktops
2560×1600 5
4
or lower
5120×2880 1
4096×2160 1
4
Virtual
V100D-1B4 1024 32 32 16384000 3840×2160 1
Desktops
2560×1600 5
4
or lower
Virtual
Frame Maximum Maximum Maximum
Virtual Intended Displays
Buffer vGPUs vGPUs Display
GPU Type Use Case per
(MB) per GPU per Board Resolution
vGPU
Training 2
V100D-32C 32768 1 1 4096×2160 1
Workloads
Training 2
V100D-16C 16384 2 2 4096×2160 1
Workloads
Virtual
Frame Maximum Maximum Maximum
Virtual Intended Displays
Buffer vGPUs vGPUs Display
GPU Type Use Case per
(MB) per GPU per Board Resolution
vGPU
Training 2
V100D-8C 8192 4 4 4096×2160 1
Workloads
Inference 2
V100D-4C 4096 8 8 4096×2160 1
Workloads
Virtual
Frame Maximum Maximum Maximum
Virtual Intended Displays
Buffer vGPUs vGPUs Display
GPU Type Use Case per
(MB) per GPU per Board Resolution
vGPU
Virtual 6 6
V100D-32A 32768 1 1 1280×1024 1
Applications
Virtual 6 6
V100D-16A 16384 2 2 1280×1024 1
Applications
Virtual 6 6
V100D-8A 8192 4 4 1280×1024 1
Applications
Virtual 6 6
V100D-4A 4096 8 8 1280×1024 1
Applications
Virtual 6 6
V100D-2A 2048 16 16 1280×1024 1
Applications
Virtual 6 6
V100D-1A 1024 32 32 1280×1024 1
Applications
on a configuration in which all displays have the same resolution. For examples of
configurations with a mixture of display resolutions, see Mixed Display Configurations for
B-Series and Q-Series vGPUs.
Maximum Virtual
Frame Maximum
Virtual Intended vGPUs Available Display Displays
Buffer vGPUs
GPU Type Use Case per Pixels Resolution per
(MB) per GPU
Board vGPU
7680×4320 2
Virtual
V100S-32Q 32768 1 1 66355200 5120×2880
Workstations 4
or lower
7680×4320 2
Virtual
V100S-16Q 16384 2 2 66355200 5120×2880
Workstations 4
or lower
7680×4320 2
Virtual
V100S-8Q 8192 4 4 66355200 5120×2880
Workstations 4
or lower
7680×4320 1
Virtual
V100S-4Q 4096 8 8 58982400 5120×2880
Workstations 4
or lower
7680×4320 1
Virtual 5120×2880 2
V100S-2Q 2048 16 16 35389440
Workstations 4096×2160
4
or lower
5120×2880 1
Virtual
4096×2160 2
Desktops,
V100S-1Q 1024 32 32 17694720 3840×2160 2
Virtual
Workstations 2560×1600
4
or lower
configurations with a mixture of display resolutions, see Mixed Display Configurations for
B-Series and Q-Series vGPUs.
Maximum Virtual
Frame Maximum
Virtual Intended vGPUs Available Display Displays
Buffer vGPUs
GPU Type Use Case per Pixels Resolution per
(MB) per GPU
Board vGPU
5120×2880 1
4096×2160 2
Virtual
V100S-2B 2048 16 16 17694720 3840×2160 2
Desktops
2560×1600
4
or lower
5120×2880 1
4096×2160 1
Virtual
V100S-1B 1024 32 32 16384000 3840×2160 1
Desktops
2560×1600 5
4
or lower
Virtual
Frame Maximum Maximum Maximum
Virtual Intended Displays
Buffer vGPUs vGPUs Display
GPU Type Use Case per
(MB) per GPU per Board Resolution
vGPU
Training 2
V100S-32C 32768 1 1 4096×2160 1
Workloads
Training 2
V100S-16C 16384 2 2 4096×2160 1
Workloads
Training 2
V100S-8C 8192 4 4 4096×2160 1
Workloads
Inference 2
V100S-4C 4096 8 8 4096×2160 1
Workloads
Virtual
Frame Maximum Maximum Maximum
Virtual Intended Displays
Buffer vGPUs vGPUs Display
GPU Type Use Case per
(MB) per GPU per Board Resolution
vGPU
Virtual 6 6
V100S-32A 32768 1 1 1280×1024 1
Applications
Virtual 6 6
V100S-16A 16384 2 2 1280×1024 1
Applications
Virtual 6 6
V100S-8A 8192 4 4 1280×1024 1
Applications
Virtual 6 6
V100S-4A 4096 8 8 1280×1024 1
Applications
Virtual 6 6
V100S-2A 2048 16 16 1280×1024 1
Applications
Virtual 6 6
V100S-1A 1024 32 32 1280×1024 1
Applications
Maximum Virtual
Frame Maximum
Virtual Intended vGPUs Available Display Displays
Buffer vGPUs
GPU Type Use Case per Pixels Resolution per
(MB) per GPU
Board vGPU
7680×4320 2
Virtual
V100L-16Q 16384 1 1 66355200 5120×2880
Workstations 4
or lower
Virtual
V100L-8Q 8192 2 2 66355200 7680×4320 2
Workstations
Maximum Virtual
Frame Maximum
Virtual Intended vGPUs Available Display Displays
Buffer vGPUs
GPU Type Use Case per Pixels Resolution per
(MB) per GPU
Board vGPU
5120×2880
4
or lower
7680×4320 1
Virtual
V100L-4Q 4096 4 4 58982400 5120×2880
Workstations 4
or lower
7680×4320 1
Virtual 5120×2880 2
V100L-2Q 2048 8 8 35389440
Workstations 4096×2160
4
or lower
5120×2880 1
Virtual
4096×2160 2
Desktops,
V100L-1Q 1024 16 16 17694720 3840×2160 2
Virtual
Workstations 2560×1600
4
or lower
Maximum Virtual
Frame Maximum
Virtual Intended vGPUs Available Display Displays
Buffer vGPUs
GPU Type Use Case per Pixels Resolution per
(MB) per GPU
Board vGPU
5120×2880 1
4096×2160 2
Virtual
V100L-2B 2048 8 8 17694720 3840×2160 2
Desktops
2560×1600
4
or lower
Maximum Virtual
Frame Maximum
Virtual Intended vGPUs Available Display Displays
Buffer vGPUs
GPU Type Use Case per Pixels Resolution per
(MB) per GPU
Board vGPU
5120×2880 1
4096×2160 2
4
Virtual
V100L-2B4 2048 8 8 17694720 3840×2160 2
Desktops
2560×1600
4
or lower
5120×2880 1
4096×2160 1
Virtual
V100L-1B 1024 16 16 16384000 3840×2160 1
Desktops
2560×1600 5
4
or lower
5120×2880 1
4096×2160 1
4
Virtual
V100L-1B4 1024 16 16 16384000 3840×2160 1
Desktops
2560×1600 5
4
or lower
Virtual
Frame Maximum Maximum Maximum
Virtual Intended Displays
Buffer vGPUs vGPUs Display
GPU Type Use Case per
(MB) per GPU per Board Resolution
vGPU
Training 2
V100L-16C 16384 1 1 4096×2160 1
Workloads
Training 2
V100L-8C 8192 2 2 4096×2160 1
Workloads
Inference 2
V100L-4C 4096 4 4 4096×2160 1
Workloads
These vGPU types support a single display with a fixed maximum resolution.
Virtual
Frame Maximum Maximum Maximum
Virtual Intended Displays
Buffer vGPUs vGPUs Display
GPU Type Use Case per
(MB) per GPU per Board Resolution
vGPU
Virtual 6 6
V100L-16A 16384 1 1 1280×1024 1
Applications
Virtual 6 6
V100L-8A 8192 2 2 1280×1024 1
Applications
Virtual 6 6
V100L-4A 4096 4 4 1280×1024 1
Applications
Virtual 6 6
V100L-2A 2048 8 8 1280×1024 1
Applications
Virtual 6 6
V100L-1A 1024 16 16 1280×1024 1
Applications
Maximum Virtual
Frame Maximum
Virtual Intended vGPUs Available Display Displays
Buffer vGPUs
GPU Type Use Case per Pixels Resolution per
(MB) per GPU
Board vGPU
7680×4320 2
Virtual
RTX8000-48Q 49152 1 1 66355200 5120×2880
Workstations 4
or lower
7680×4320 2
Virtual
RTX8000-24Q 24576 2 2 66355200 5120×2880
Workstations 4
or lower
Maximum Virtual
Frame Maximum
Virtual Intended vGPUs Available Display Displays
Buffer vGPUs
GPU Type Use Case per Pixels Resolution per
(MB) per GPU
Board vGPU
7680×4320 2
Virtual
RTX8000-16Q 16384 3 3 66355200 5120×2880
Workstations 4
or lower
7680×4320 2
Virtual
RTX8000-12Q 12288 4 4 66355200 5120×2880
Workstations 4
or lower
7680×4320 2
Virtual
RTX8000-8Q 8192 6 6 66355200 5120×2880
Workstations 4
or lower
7680×4320 1
Virtual
RTX8000-6Q 6144 8 8 58982400 5120×2880
Workstations 4
or lower
7680×4320 1
Virtual
RTX8000-4Q 4096 12 12 58982400 5120×2880
Workstations 4
or lower
7680×4320 1
Virtual 5120×2880 2
RTX8000-3Q 3072 16 16 35389440
Workstations 4096×2160
4
or lower
7680×4320 1
Virtual 5120×2880 2
RTX8000-2Q 2048 24 24 35389440
Workstations 4096×2160
4
or lower
5120×2880 1
4096×2160 2
Virtual 9
RTX8000-1Q 1024 32 32 17694720 3840×2160 2
Workstations
2560×1600
4
or lower
9
The maximum vGPUs per GPU is limited to 32.
These vGPU types support a maximum combined resolution based on the number of
available pixels, which is determined by their frame buffer size. You can choose between
using a small number of high resolution displays or a larger number of lower resolution
displays with these vGPU types. The maximum number of displays per vGPU is based
on a configuration in which all displays have the same resolution. For examples of
configurations with a mixture of display resolutions, see Mixed Display Configurations for
B-Series and Q-Series vGPUs.
Maximum Virtual
Frame Maximum
Virtual Intended vGPUs Available Display Displays
Buffer vGPUs
GPU Type Use Case per Pixels Resolution per
(MB) per GPU
Board vGPU
5120×2880 1
4096×2160 2
Virtual
RTX8000-2B 2048 24 24 17694720 3840×2160 2
Desktops
2560×1600
4
or lower
5120×2880 1
4096×2160 1
Virtual
RTX8000-1B 1024 32 32 16384000 3840×2160 1
Desktops
2560×1600 5
4
or lower
Virtual
Frame Maximum Maximum Maximum
Virtual Intended Displays
Buffer vGPUs vGPUs Display
GPU Type Use Case per
(MB) per GPU per Board Resolution
vGPU
Training 2
RTX8000-48C 49152 1 1 4096×2160 1
Workloads
Training 2
RTX8000-24C 24576 2 2 4096×2160 1
Workloads
Training 2
RTX8000-16C 16384 3 3 4096×2160 1
Workloads
Training 2
RTX8000-12C 12288 4 4 4096×2160 1
Workloads
Virtual
Frame Maximum Maximum Maximum
Virtual Intended Displays
Buffer vGPUs vGPUs Display
GPU Type Use Case per
(MB) per GPU per Board Resolution
vGPU
Training 2
RTX8000-8C 8192 6 6 4096×2160 1
Workloads
Training 2
RTX8000-6C 6144 8 8 4096×2160 1
Workloads
Inference 3 2
RTX8000-4C 4096 8 8 4096×2160 1
Workloads
Virtual
Frame Maximum Maximum Maximum
Virtual Intended Displays
Buffer vGPUs vGPUs Display
GPU Type Use Case per
(MB) per GPU per Board Resolution
vGPU
Virtual 6 6
RTX8000-48A 49152 1 1 1280×1024 1
Applications
Virtual 6 6
RTX8000-24A 24576 2 2 1280×1024 1
Applications
Virtual 6 6
RTX8000-16A 16384 3 3 1280×1024 1
Applications
Virtual 6 6
RTX8000-12A 12288 4 4 1280×1024 1
Applications
Virtual 6 6
RTX8000-8A 8192 6 6 1280×1024 1
Applications
Virtual 6 6
RTX8000-6A 6144 8 8 1280×1024 1
Applications
Virtual 6 6
RTX8000-4A 4096 12 12 1280×1024 1
Applications
Virtual 6 6
RTX8000-3A 3072 16 16 1280×1024 1
Applications
Virtual 6 6
RTX8000-2A 2048 24 24 1280×1024 1
Applications
Virtual 9 6 6
RTX8000-1A 1024 32 32 1280×1024 1
Applications
Maximum Virtual
Frame Maximum
Virtual Intended vGPUs Available Display Displays
Buffer vGPUs
GPU Type Use Case per Pixels Resolution per
(MB) per GPU
Board vGPU
7680×4320 2
Virtual
RTX8000P-48Q 49152 1 1 66355200 5120×2880
Workstations 4
or lower
7680×4320 2
Virtual
RTX8000P-24Q 24576 2 2 66355200 5120×2880
Workstations 4
or lower
7680×4320 2
Virtual
RTX8000P-16Q 16384 3 3 66355200 5120×2880
Workstations 4
or lower
7680×4320 2
Virtual
RTX8000P-12Q 12288 4 4 66355200 5120×2880
Workstations 4
or lower
7680×4320 2
Virtual
RTX8000P-8Q 8192 6 6 66355200 5120×2880
Workstations 4
or lower
7680×4320 1
Virtual
RTX8000P-6Q 6144 8 8 58982400 5120×2880
Workstations 4
or lower
Maximum Virtual
Frame Maximum
Virtual Intended vGPUs Available Display Displays
Buffer vGPUs
GPU Type Use Case per Pixels Resolution per
(MB) per GPU
Board vGPU
7680×4320 1
Virtual
RTX8000P-4Q 4096 12 12 58982400 5120×2880
Workstations 4
or lower
7680×4320 1
Virtual 5120×2880 2
RTX8000P-3Q 3072 16 16 35389440
Workstations 4096×2160
4
or lower
7680×4320 1
Virtual 5120×2880 2
RTX8000P-2Q 2048 24 24 35389440
Workstations 4096×2160
4
or lower
5120×2880 1
4096×2160 2
Virtual 10
RTX8000P-1Q 1024 32 32 17694720 3840×2160 2
Workstations
2560×1600
4
or lower
Maximum Virtual
Frame Maximum
Virtual Intended vGPUs Available Display Displays
Buffer vGPUs
GPU Type Use Case per Pixels Resolution per
(MB) per GPU
Board vGPU
Virtual 5120×2880 1
RTX8000P-2B 2048 24 24 17694720
Desktops 4096×2160 2
10
The maximum vGPUs per GPU is limited to 32.
Maximum Virtual
Frame Maximum
Virtual Intended vGPUs Available Display Displays
Buffer vGPUs
GPU Type Use Case per Pixels Resolution per
(MB) per GPU
Board vGPU
3840×2160 2
2560×1600
4
or lower
5120×2880 1
4096×2160 1
Virtual
RTX8000P-1B 1024 32 32 16384000 3840×2160 1
Desktops
2560×1600 5
4
or lower
Virtual
Frame Maximum Maximum Maximum
Virtual Intended Displays
Buffer vGPUs vGPUs Display
GPU Type Use Case per
(MB) per GPU per Board Resolution
vGPU
Training 2
RTX8000P-48C 49152 1 1 4096×2160 1
Workloads
Training 2
RTX8000P-24C 24576 2 2 4096×2160 1
Workloads
Training 2
RTX8000P-16C 16384 3 3 4096×2160 1
Workloads
Training 2
RTX8000P-12C 12288 4 4 4096×2160 1
Workloads
Training 2
RTX8000P-8C 8192 6 6 4096×2160 1
Workloads
Training 2
RTX8000P-6C 6144 8 8 4096×2160 1
Workloads
Inference 3 2
RTX8000P-4C 4096 8 8 4096×2160 1
Workloads
These vGPU types support a single display with a fixed maximum resolution.
Virtual
Frame Maximum Maximum Maximum
Virtual Intended Displays
Buffer vGPUs vGPUs Display
GPU Type Use Case per
(MB) per GPU per Board Resolution
vGPU
Virtual 6 6
RTX8000P-48A 49152 1 1 1280×1024 1
Applications
Virtual 6 6
RTX8000P-24A 24576 2 2 1280×1024 1
Applications
Virtual 6 6
RTX8000P-16A 16384 3 3 1280×1024 1
Applications
Virtual 6 6
RTX8000P-12A 12288 4 4 1280×1024 1
Applications
Virtual 6 6
RTX8000P-8A 8192 6 6 1280×1024 1
Applications
Virtual 6 6
RTX8000P-6A 6144 8 8 1280×1024 1
Applications
Virtual 6 6
RTX8000P-4A 4096 12 12 1280×1024 1
Applications
Virtual 6 6
RTX8000P-3A 3072 16 16 1280×1024 1
Applications
Virtual 6 6
RTX8000P-2A 2048 24 24 1280×1024 1
Applications
Virtual 10 6 6
RTX8000P-1A 1024 32 32 1280×1024 1
Applications
Maximum Virtual
Frame Maximum
Virtual Intended vGPUs Available Display Displays
Buffer vGPUs
GPU Type Use Case per Pixels Resolution per
(MB) per GPU
Board vGPU
7680×4320 2
Virtual
RTX6000-24Q 24576 1 1 66355200 5120×2880
Workstations 4
or lower
7680×4320 2
Virtual
RTX6000-12Q 12288 2 2 66355200 5120×2880
Workstations 4
or lower
7680×4320 2
Virtual
RTX6000-8Q 8192 3 3 66355200 5120×2880
Workstations 4
or lower
7680×4320 1
Virtual
RTX6000-6Q 6144 4 4 58982400 5120×2880
Workstations 4
or lower
7680×4320 1
Virtual
RTX6000-4Q 4096 6 6 58982400 5120×2880
Workstations 4
or lower
7680×4320 1
Virtual 5120×2880 2
RTX6000-3Q 3072 8 8 35389440
Workstations 4096×2160
4
or lower
7680×4320 1
Virtual 5120×2880 2
RTX6000-2Q 2048 12 12 35389440
Workstations 4096×2160
4
or lower
5120×2880 1
4096×2160 2
Virtual
RTX6000-1Q 1024 24 24 17694720 3840×2160 2
Workstations
2560×1600
4
or lower
These vGPU types support a maximum combined resolution based on the number of
available pixels, which is determined by their frame buffer size. You can choose between
using a small number of high resolution displays or a larger number of lower resolution
displays with these vGPU types. The maximum number of displays per vGPU is based
on a configuration in which all displays have the same resolution. For examples of
configurations with a mixture of display resolutions, see Mixed Display Configurations for
B-Series and Q-Series vGPUs.
Maximum Virtual
Frame Maximum
Virtual Intended vGPUs Available Display Displays
Buffer vGPUs
GPU Type Use Case per Pixels Resolution per
(MB) per GPU
Board vGPU
5120×2880 1
4096×2160 2
Virtual
RTX6000-2B 2048 12 12 17694720 3840×2160 2
Desktops
2560×1600
4
or lower
5120×2880 1
4096×2160 1
Virtual
RTX6000-1B 1024 24 24 16384000 3840×2160 1
Desktops
2560×1600 5
4
or lower
Virtual
Frame Maximum Maximum Maximum
Virtual Intended Displays
Buffer vGPUs vGPUs Display
GPU Type Use Case per
(MB) per GPU per Board Resolution
vGPU
Training 2
RTX6000-24C 24576 1 1 4096×2160 1
Workloads
Training 2
RTX6000-12C 12288 2 2 4096×2160 1
Workloads
Training 2
RTX6000-8C 8192 3 3 4096×2160 1
Workloads
Training 2
RTX6000-6C 6144 4 4 4096×2160 1
Workloads
Virtual
Frame Maximum Maximum Maximum
Virtual Intended Displays
Buffer vGPUs vGPUs Display
GPU Type Use Case per
(MB) per GPU per Board Resolution
vGPU
Inference 2
RTX6000-4C 4096 6 6 4096×2160 1
Workloads
Virtual
Frame Maximum Maximum Maximum
Virtual Intended Displays
Buffer vGPUs vGPUs Display
GPU Type Use Case per
(MB) per GPU per Board Resolution
vGPU
Virtual 6 6
RTX6000-24A 24576 1 1 1280×1024 1
Applications
Virtual 6 6
RTX6000-12A 12288 2 2 1280×1024 1
Applications
Virtual 6 6
RTX6000-8A 8192 3 3 1280×1024 1
Applications
Virtual 6 6
RTX6000-6A 6144 4 4 1280×1024 1
Applications
Virtual 6 6
RTX6000-4A 4096 6 6 1280×1024 1
Applications
Virtual 6 6
RTX6000-3A 3072 8 8 1280×1024 1
Applications
Virtual 6 6
RTX6000-2A 2048 12 12 1280×1024 1
Applications
Virtual 6 6
RTX6000-1A 1024 24 24 1280×1024 1
Applications
These vGPU types support a maximum combined resolution based on the number of
available pixels, which is determined by their frame buffer size. You can choose between
using a small number of high resolution displays or a larger number of lower resolution
displays with these vGPU types. The maximum number of displays per vGPU is based
on a configuration in which all displays have the same resolution. For examples of
configurations with a mixture of display resolutions, see Mixed Display Configurations for
B-Series and Q-Series vGPUs.
Maximum Virtual
Frame Maximum
Virtual Intended vGPUs Available Display Displays
Buffer vGPUs
GPU Type Use Case per Pixels Resolution per
(MB) per GPU
Board vGPU
7680×4320 2
Virtual
RTX6000P-24Q 24576 1 1 66355200 5120×2880
Workstations 4
or lower
7680×4320 2
Virtual
RTX6000P-12Q 12288 2 2 66355200 5120×2880
Workstations 4
or lower
7680×4320 2
Virtual
RTX6000P-8Q 8192 3 3 66355200 5120×2880
Workstations 4
or lower
7680×4320 1
Virtual
RTX6000P-6Q 6144 4 4 58982400 5120×2880
Workstations 4
or lower
7680×4320 1
Virtual
RTX6000P-4Q 4096 6 6 58982400 5120×2880
Workstations 4
or lower
7680×4320 1
Virtual 5120×2880 2
RTX6000P-3Q 3072 8 8 35389440
Workstations 4096×2160
4
or lower
7680×4320 1
Virtual 5120×2880 2
RTX6000P-2Q 2048 12 12 35389440
Workstations 4096×2160
4
or lower
5120×2880 1
Virtual
RTX6000P-1Q 1024 24 24 17694720 4096×2160 2
Workstations
3840×2160 2
Maximum Virtual
Frame Maximum
Virtual Intended vGPUs Available Display Displays
Buffer vGPUs
GPU Type Use Case per Pixels Resolution per
(MB) per GPU
Board vGPU
2560×1600
4
or lower
Maximum Virtual
Frame Maximum
Virtual Intended vGPUs Available Display Displays
Buffer vGPUs
GPU Type Use Case per Pixels Resolution per
(MB) per GPU
Board vGPU
5120×2880 1
4096×2160 2
Virtual
RTX6000P-2B 2048 12 12 17694720 3840×2160 2
Desktops
2560×1600
4
or lower
5120×2880 1
4096×2160 1
Virtual
RTX6000P-1B 1024 24 24 16384000 3840×2160 1
Desktops
2560×1600 5
4
or lower
Virtual
Frame Maximum Maximum Maximum
Virtual Intended Displays
Buffer vGPUs vGPUs Display
GPU Type Use Case per
(MB) per GPU per Board Resolution
vGPU
Training 2
RTX6000P-24C 24576 1 1 4096×2160 1
Workloads
Training 2
RTX6000P-12C 12288 2 2 4096×2160 1
Workloads
Training 2
RTX6000P-8C 8192 3 3 4096×2160 1
Workloads
Training 2
RTX6000P-6C 6144 4 4 4096×2160 1
Workloads
Inference 2
RTX6000P-4C 4096 6 6 4096×2160 1
Workloads
Virtual
Frame Maximum Maximum Maximum
Virtual Intended Displays
Buffer vGPUs vGPUs Display
GPU Type Use Case per
(MB) per GPU per Board Resolution
vGPU
Virtual 6 6
RTX6000P-24A 24576 1 1 1280×1024 1
Applications
Virtual 6 6
RTX6000P-12A 12288 2 2 1280×1024 1
Applications
Virtual 6 6
RTX6000P-8A 8192 3 3 1280×1024 1
Applications
Virtual 6 6
RTX6000P-6A 6144 4 4 1280×1024 1
Applications
Virtual 6 6
RTX6000P-4A 4096 6 6 1280×1024 1
Applications
Virtual 6 6
RTX6000P-3A 3072 8 8 1280×1024 1
Applications
Virtual 6 6
RTX6000P-2A 2048 12 12 1280×1024 1
Applications
Virtual 6 6
RTX6000P-1A 1024 24 24 1280×1024 1
Applications
Strategies for allocating physical hardware resources to VMs and vGPUs can improve
the performance of VMs running with NVIDIA vGPU. They include strategies for pinning
VM CPU cores to physical cores on Non-Uniform Memory Access (NUMA) platforms,
allocating VMs to CPUs, and allocating vGPUs to physical GPUs. These allocation
strategies are supported by Citrix Hypervisor and VMware vSphere.
the least-loaded CPU socket, and allocate the VM’s vGPU on an available, least-loaded,
physical GPU connected via that socket.
Citrix Hypervisor and VMware vSphere ESXi use a different GPU allocation policy by
default.
‣ Citrix Hypervisor creates GPU groups with a default allocation policy of depth-first.
See Modifying GPU Allocation Policy on Citrix Hypervisor for details on switching the
allocation policy to breadth-first.
‣ VMware vSphere ESXi creates GPU groups with a default allocation policy of breadth-
first.
See Modifying GPU Allocation Policy on VMware vSphere for details on switching the
allocation policy to depth-first.
Note: Due to vGPU’s requirement that only one type of vGPU can run on a physical GPU at
any given time, not all physical GPUs may be available to host the vGPU type required by
the new VM.
x11vnc is a virtual network computing (VNC) server that provides remote access to an
existing X session with any VNC viewer. You can use x11vnc to confirm that the NVIDIA
GPU in a Linux server to which no display devices are directly connected is working as
expected. Examples of servers to which no display devices are directly connected include
a VM that is configured with NVIDIA vGPU, a VM that is configured with a pass-through
GPU, and a headless physical host in a bare-metal deployment.
Before you begin, ensure that the following prerequisites are met:
‣ The NVIDIA vGPU software software graphics driver for Linux is installed on the server.
‣ A secure shell (SSH) client is installed on your local system:
‣ On Windows, you must use a third-party SSH client such as PuTTY.
‣ On Linux, you can run the SSH client that is included with the OS from a shell or
terminal window.
Configuring x11vnc involves following the sequence of instructions in these sections:
1. Configuring the Xorg Server on the Linux Server
2. Installing and Configuring x11vnc on the Linux Server
3. Using a VNC Client to Connect to the Linux Server
After connecting to the server, you can use NVIDIA X Server Settings to confirm that the
NVIDIA GPU is working as expected.
GPU #0:
Name : GRID T4-2Q
UUID : GPU-ea80de2d-1dd8-11b2-8305-c955f034e718
PCI BusID : PCI:2:2:0
Note: The three numbers in the PCI BusID obtained by nvidia-xconfig in the
previous step are hexadecimal numbers. They must be converted to decimal
numbers in the PCI bus identifier in the Device section. For example, if the PCI
bus identifier obtained in the previous step is PCI:A:10:0, it must be specified as
PCI:10:16:0 in the PCI bus identifier in the Device section.
# ps -ef | grep X
On Red Hat Enterprise Linux, this command displays output similar to the following
example.
root 5285 5181 0 16:29 pts/0 00:00:00 grep --color=auto X
root 5880 1 0 Jun13 ? 00:00:00 /usr/bin/abrt-watch-log -F
Backtrace /var/log/Xorg.0.log -- /usr/bin/abrt-dump-xorg -xD
root 7039 6289 0 Jun13 tty1 00:00:03 /usr/bin/X :0 -background none -
noreset -audit 4 -verbose -auth /run/gdm/auth-for-gdm-vr4MFC/database -seat seat0
vt1
‣ For distributions based on Red Hat, use the yum package manager to install the
x11vnc package.
# yum install x11vnc
‣ For distributions based on Debian, use the apt package manager to install the
x11vnc package.
# sudo apt install x11vnc
‣ For SuSE Linux distributions, install x11vnc from the x11vnc openSUSE Software
page.
2. Get the display numbers of the servers for the Xorg server.
# cat /proc/*/environ 2>/dev/null | tr '\0' '\n' | grep '^DISPLAY=:' | uniq
DISPLAY=:0
DISPLAY=:100
3. Start the x11vnc server, specifying the display number to use.
The following example starts the x11vnc server on display 0 on a Linux server that is
running the Gnome desktop.
# x11vnc -display :0 -auth /run/user/121/gdm/Xauthority -forever \
-shared -ncache -bg
Note: If you are using a C-series vGPU, omit the -ncache option.
PORT=5900
Troubleshooting: If your VNC client cannot connect to the server, change permissions on
the Linux server as follows:
1. Allow the VNC client to connect to the server by making one of the following changes:
Administrators can disable the NVIDIA Notification Icon application for all users'
sessions as explained in Disabling NVIDIA Notification Icon for All Users' Citrix Published
Application Sessions.
Individual users can disable the NVIDIA Notification Icon application for their own
sessions as explained in Disabling NVIDIA Notification Icon for your Citrix Published
Application User Sessions.
Note: If an administrator has enabled the NVIDIA Notification Icon application for the
administrator's own session, the application is enabled for all users' sessions, even the
sessions of users who have previously disabled the application.
The data value 0 disables the NVIDIA Notification Icon, and the data value 1 enables
it.
2. Restart the VM.
You must restart the VM to ensure that the registry key is set before the NVIDIA
service in the user session starts.
The data value 0 disables the NVIDIA Notification Icon, and the data value 1 enables
it.
2. Log off and log on again or restart the VM.
You must log on and log off again or restart the VM to ensure that the registry key is
set before the NVIDIA service in the user session starts.
To install and configure NVIDIA vGPU software and optimize Citrix Hypervisor operation
with vGPU, some basic operations on Citrix Hypervisor are needed.
‣ If you are running the client from dom0, use the secure copy command scp.
The scp command is part of the SSH suite of applications. It is implemented in dom0
and can be used to copy from a remote SSH-enabled server:
[root@xenserver ~]# scp root@10.31.213.96:/tmp/somefile .
The authenticity of host '10.31.213.96 (10.31.213.96)' can't be established.
RSA key fingerprint is 26:2d:9b:b9:bf:6c:81:70:36:76:13:02:c1:82:3d:3c.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '10.31.213.96' (RSA) to the list of known hosts.
root@10.31.213.96's password:
somefile 100% 532 0.5KB/s 00:00
[root@xenserver ~]#
‣ If you are running the client from Windows, use the pscp program.
The pscp program is part of the PuTTY suite and can be used to copy files from a
remote Windows system to Citrix Hypervisor:
C:\Users\nvidia>pscp somefile root@10.31.213.98:/tmp
root@10.31.213.98's password:
somefile | 80 kB | 80.1 kB/s | ETA: 00:00:00 | 100%
C:\Users\nvidia>
‣ To list all VMs and their associated UUIDs, use xe vm-list without any parameters:
[root@xenserver ~]# xe vm-list
uuid ( RO) : 6b5585f6-bd74-2e3e-0e11-03b9281c3ade
name-label ( RW): vgx-base-image-win7-64
power-state ( RO): halted
vm-uuid is the VM’s UUID, which you can obtain as explained in Determining a VM’s UUID.
vendor: GenuineIntel
speed: 2600.064
modelname: Intel(R) Xeon(R) CPU E5-2670 0 @ 2.60GHz
family: 6
model: 45
stepping: 7
flags: fpu de tsc msr pae mce cx8 apic sep mtrr mca cmov pat
clflush acpi mmx fxsr sse sse2 ss ht nx constant_tsc nonstop_tsc aperfmperf
pni pclmulqdq vmx est ssse3 sse4_1 sse4_2 x2apic popcnt aes hypervisor ida arat
tpr_shadow vnmi flexpriority ept vpid
features: 17bee3ff-bfebfbff-00000001-2c100800
features_after_reboot: 17bee3ff-bfebfbff-00000001-2c100800
physical_features: 17bee3ff-bfebfbff-00000001-2c100800
maskable: full
2. Set VCPUs-params:mask to pin a VM’s vCPUs to a specific socket or to specific cores
within a socket.
This setting persists over VM reboots and shutdowns. In a dual socket platform with
32 total cores, cores 0-15 are on socket 0, and cores 16-31 are on socket 1.
In the examples that follow, vm-uuid is the VM’s UUID, which you can obtain as
explained in Determining a VM’s UUID.
‣ To restrict a VM to only run on socket 0, set the mask to specify cores 0-15:
[root@xenserver ~]# xe vm-param-set uuid=vm-uuid VCPUs-
params:mask=0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15
‣ To restrict a VM to only run on socket 1, set the mask to specify cores 16-31:
[root@xenserver ~]# xe vm-param-set uuid=vm-uuid VCPUs-
params:mask=16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31
‣ To pin vCPUs to specific cores within a socket, set the mask to specify the cores
directly:
You can perform Citrix Hypervisor advanced vGPU management techniques by using
XenCenter and by using xe command line operations.
[root@xenserver ~]#
Creating the vgpu object for a VM does not immediately cause a virtual GPU to be created
on a physical GPU. Instead, the vgpu object is created whenever its associated VM is
started. For more details on how vGPUs are created at VM startup, see Controlling vGPU
allocation.
Note:
The owning VM must be in the powered-off state in order for the vgpu-create command
to succeed.
A vgpu object’s owning VM, associated GPU group, and vGPU type are fixed at creation and
cannot be subsequently changed. To change the type of vGPU allocated to a VM, delete
the existing vgpu object and create another one.
‣ The GPU group that the vgpu object is associated with is checked for a physical GPU
that can host a vGPU of the required type (i.e. the vgpu object’s associated vgpu-
type). Because vGPU types cannot be mixed on a single physical GPU, the new vGPU
can only be created on a physical GPU that has no vGPUs resident on it, or only vGPUs
of the same type, and less than the limit of vGPUs of that type that the physical GPU
can support.
‣ If no such physical GPUs exist in the group, the vgpu creation fails and the VM startup
is aborted.
‣ Otherwise, if more than one such physical GPU exists in the group, a physical GPU is
selected according to the GPU group’s allocation policy, as described in Modifying GPU
Allocation Policy.
Note: If the vGPU is not currently running, the resident-on parameter is not instantiated
for the vGPU, and the vgpu-param-get operation returns:
<not in database>
Note: The pci-id parameter passed to the pgpu-list command must be in the exact
format shown, with the PCI domain fully specified (for example, 0000) and the PCI bus
and devices numbers each being two digits (for example, 87:00.0).
3. Ensure that no vGPUs are currently operating on the physical GPU by checking the
resident-VGPUs parameter:
[root@xenserver ~]# xe pgpu-param-get uuid=f76d1c90-e443-4bfc-8f26-7959a7c85c68 param-
name=resident-VGPUs
[root@xenserver ~]#
4. If any vGPUs are listed, shut down the VMs associated with them.
5. Change the gpu-group-uuid parameter of the physical GPU to the UUID of the newly-
created GPU group:
[root@xenserver ~]# xe pgpu-param-set uuid=7c1e3cff-1429-0544-df3d-bf8a086fb70a gpu-
group-uuid=585877ef-5a6c-66af-fc56-7bd525bdc2f6
[root@xenserver ~]#
Any vgpu object now created that specifies this GPU group UUID will always have its
vGPUs created on the GPU at PCI bus ID 0000:05:0.0.
Note: You can add more than one physical GPU to a manually-created GPU group – for
example, to represent all the GPUs attached to the same CPU socket in a multi-socket
server platform - but as for automatically-created GPU groups, all the physical GPUs in the
group must be of the same type.
In XenCenter, manually-created GPU groups appear in the GPU type listing in a VM’s
GPU Properties. Select a GPU type within the group from which you wish the vGPU to be
allocated:
This chapter provides recommendations on optimizing performance for VMs running with
NVIDIA vGPU on Citrix Hypervisor.
Once you have installed an alternate means of accessing a VM (such as Citrix Virtual Apps
and Desktops or a VNC server), its vGPU console VGA interface can be disabled as follows,
depending on the version of Citrix Hypervisor that you are using:
‣ Citrix Hypervisor 8.1 or later: Create the vGPU by using the xe command, and specify
plugin parameters for the group to which the vGPU belongs:
1. Create the vGPU.
[root@xenserver ~]# xe vgpu-create gpu-group-uuid=gpu-group-uuid vgpu-type-
uuid=vgpu-type-uuid vm-uuid=vm-uuid
This command returns vgpu-uuid as stored in XAPI.
2. Specify plugin parameters for the group to which the vGPU belongs.
[root@xenserver ~]# xe vgpu-param-set uuid=vgpu-uuid extra_args=disable_vnc=1
‣ Citrix Hypervisor earlier than 8.1: Specify disable_vnc=1 in the VM’s
platform:vgpu_extra_args parameter:
[root@xenserver ~]# xe vm-param-set uuid=vm-uuid
platform:vgpu_extra_args="disable_vnc=1"
The new console VGA setting takes effect the next time the VM is started or
rebooted. With console VGA disabled, the Citrix Hypervisor console will display the
Windows boot splash screen for the VM, but nothing beyond that.
CAUTION:
If you disable console VGA before you have installed or enabled an alternate mechanism to
access the VM (such as Citrix Virtual Apps and Desktops), you will not be able to interact
with the VM once it has booted.
You can recover console VGA access by making one of the following changes:
NVIDIA reserves the right to make corrections, modifications, enhancements, improvements, and any other changes to this document, at any time without
notice.
Customer should obtain the latest relevant information before placing orders and should verify that such information is current and complete.
NVIDIA products are sold subject to the NVIDIA standard terms and conditions of sale supplied at the time of order acknowledgement, unless otherwise
agreed in an individual sales agreement signed by authorized representatives of NVIDIA and customer (“Terms of Sale”). NVIDIA hereby expressly objects
to applying any customer general terms and conditions with regards to the purchase of the NVIDIA product referenced in this document. No contractual
obligations are formed either directly or indirectly by this document.
NVIDIA products are not designed, authorized, or warranted to be suitable for use in medical, military, aircraft, space, or life support equipment, nor in
applications where failure or malfunction of the NVIDIA product can reasonably be expected to result in personal injury, death, or property or environmental
damage. NVIDIA accepts no liability for inclusion and/or use of NVIDIA products in such equipment or applications and therefore such inclusion and/or use
is at customer’s own risk.
NVIDIA makes no representation or warranty that products based on this document will be suitable for any specified use. Testing of all parameters of each
product is not necessarily performed by NVIDIA. It is customer’s sole responsibility to evaluate and determine the applicability of any information contained
in this document, ensure the product is suitable and fit for the application planned by customer, and perform the necessary testing for the application in
order to avoid a default of the application or the product. Weaknesses in customer’s product designs may affect the quality and reliability of the NVIDIA
product and may result in additional or different conditions and/or requirements beyond those contained in this document. NVIDIA accepts no liability related
to any default, damage, costs, or problem which may be based on or attributable to: (i) the use of the NVIDIA product in any manner that is contrary to this
document or (ii) customer product designs.
No license, either expressed or implied, is granted under any NVIDIA patent right, copyright, or other NVIDIA intellectual property right under this document.
Information published by NVIDIA regarding third-party products or services does not constitute a license from NVIDIA to use such products or services or
a warranty or endorsement thereof. Use of such information may require a license from a third party under the patents or other intellectual property rights
of the third party, or a license from NVIDIA under the patents or other intellectual property rights of NVIDIA.
Reproduction of information in this document is permissible only if approved in advance by NVIDIA in writing, reproduced without alteration and in full
compliance with all applicable export laws and regulations, and accompanied by all associated conditions, limitations, and notices.
THIS DOCUMENT AND ALL NVIDIA DESIGN SPECIFICATIONS, REFERENCE BOARDS, FILES, DRAWINGS, DIAGNOSTICS, LISTS, AND OTHER DOCUMENTS
(TOGETHER AND SEPARATELY, “MATERIALS”) ARE BEING PROVIDED “AS IS.” NVIDIA MAKES NO WARRANTIES, EXPRESSED, IMPLIED, STATUTORY, OR
OTHERWISE WITH RESPECT TO THE MATERIALS, AND EXPRESSLY DISCLAIMS ALL IMPLIED WARRANTIES OF NONINFRINGEMENT, MERCHANTABILITY, AND
FITNESS FOR A PARTICULAR PURPOSE. TO THE EXTENT NOT PROHIBITED BY LAW, IN NO EVENT WILL NVIDIA BE LIABLE FOR ANY DAMAGES, INCLUDING
WITHOUT LIMITATION ANY DIRECT, INDIRECT, SPECIAL, INCIDENTAL, PUNITIVE, OR CONSEQUENTIAL DAMAGES, HOWEVER CAUSED AND REGARDLESS OF
THE THEORY OF LIABILITY, ARISING OUT OF ANY USE OF THIS DOCUMENT, EVEN IF NVIDIA HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.
Notwithstanding any damages that customer might incur for any reason whatsoever, NVIDIA’s aggregate and cumulative liability towards customer for the
products described herein shall be limited in accordance with the Terms of Sale for the product.
VESA DisplayPort
DisplayPort and DisplayPort Compliance Logo, DisplayPort Compliance Logo for Dual-mode Sources, and DisplayPort Compliance Logo for Active Cables are
trademarks owned by the Video Electronics Standards Association in the United States and other countries.
HDMI
HDMI, the HDMI logo, and High-Definition Multimedia Interface are trademarks or registered trademarks of HDMI Licensing LLC.
OpenCL
OpenCL is a trademark of Apple Inc. used under license to the Khronos Group Inc.
Trademarks
NVIDIA, the NVIDIA logo, NVIDIA GRID, NVIDIA GRID vGPU, NVIDIA Maxwell, NVIDIA Pascal, NVIDIA Turing, NVIDIA Volta, GPUDirect, Quadro, and Tesla are
trademarks or registered trademarks of NVIDIA Corporation in the U.S. and other countries. Other company and product names may be trademarks of the
respective companies with which they are associated.
Copyright
© 2013-2023 NVIDIA Corporation & affiliates. All rights reserved.