Grid Vgpu User Guide
Grid Vgpu User Guide
User Guide
Figure 6. Example MIG-Backed vGPU Configurations on NVIDIA A100 PCIe 40GB ...................... 17
Figure 18. Verifying NVIDIA driver operation using NVIDIA Control Panel ....................................80
Figure 24. Breadth-first allocation scheme setting for vGPU-enabled VMs ................................. 93
Figure 26. Depth-first allocation scheme setting for vGPU-enabled VMs .................................... 95
Figure 28. Using nvidia-smi from a Windows guest VM to get total resource usage by all
applications................................................................................................................................... 118
Figure 29. Using nvidia-smi from a Windows guest VM to get resource usage by individual
applications................................................................................................................................... 119
Figure 30. Using Windows Performance Monitor to monitor GPU performance ........................120
Figure 31. Using WMI Explorer to monitor GPU performance .................................................... 121
Figure 32. Including NVIDIA logs in a Citrix Hypervisor status report ........................................ 136
Figure 37. Editing a GPU’s enabled vGPU types using XenCenter .............................................. 245
Figure 38. Using a custom GPU group within XenCenter ............................................................ 247
NVIDIA vGPU software is a graphics virtualization platform that provides virtual machines
(VMs) access to NVIDIA GPU technology.
For instructions, see Installing the NVIDIA vGPU Software Graphics Driver.
2. License any NVIDIA vGPU software that you are using.
For instructions, see Virtual GPU Client Licensing User Guide.
3. Configure the platform for remote access.
To use graphics features with Tesla GPUs, you must use a supported remoting solution,
for example, RemoteFX, Citrix Virtual Apps and Desktops, VNC, or similar technology.
4. Use the display settings feature of the host OS to configure the Tesla GPU as the primary
display.
NVIDIA Tesla generally operates as a secondary device on bare-metal platforms.
5. If the system has multiple display adapters, disable display devices connected through
adapters that are not from NVIDIA.
You can use the display settings feature of the host OS or the remoting solution for this
purpose. On NVIDIA GPUs, including Tesla GPUs, a default display device is enabled.
Users can launch applications that require NVIDIA GPU technology for enhanced user
experience only after displays that are driven by NVIDIA adapters are enabled.
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.
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.
‣ OpenGL® 4.6
‣ Vulkan® 1.1
‣ DirectX 11
‣ DirectX 12 (Windows 10)
‣ Direct2D
‣ DirectX Video Acceleration (DXVA)
‣ NVIDIA® CUDA® 11.2
‣ NVIDIA vGPU software SDK (remote graphics acceleration)
‣ NVIDIA RTX (on GPUs based on the NVIDIA Volta graphic architecture and later
architectures)
‣ The 8Q vGPU type on Tesla M6, Tesla M10, and Tesla M60 GPUs
‣ All Q-series vGPU types on the following GPUs:
‣ Since 12.2: NVIDIA A10
‣ NVIDIA A40
‣ Since 12.2: 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
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.
NVIDIA vGPU does not support the following NVIDIA CUDA Toolkit features:
Note: These features are supported in GPU pass-through mode and in bare-metal
deployments.
For more information about NVIDIA CUDA Toolkit, see CUDA Toolkit 11.2 Documentation.
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 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.
NVIDIA GPU Operator supports automated configuration of NVIDIA vGPU software and
provides telemetry support through DCGM Exporter running in a guest VM.
NVIDIA GPU Operator is supported only on specific combinations of hypervisor software
release, container platform, vGPU type, and guest OS release. To determine if your
configuration supports NVIDIA GPU Operator with NVIDIA vGPU deployments, consult the
release notes for your chosen hypervisor at NVIDIA Virtual GPU Software Documentation.
For more information, see NVIDIA GPU Operator Overview on the NVIDIA documentation
portal.
‣ 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.
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, the 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.
3
The maximum number of NVIDIA Virtual Compute Server vGPUs is limited to eight vGPUs per physical GPU, irrespective of the
available hardware resources of the physical GPU.
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 M60-2Q is allocated 2048
Mbytes of frame buffer on a Tesla M60 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, a
Tesla M60 board can support up to 4 M60-2Q vGPUs on each of its two physical GPUs, for a
total of 8 vGPUs, but only 2 M60-4Q vGPUs, for a total of 4 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.
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
‣ 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: 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
‣ NVIDIA RTX A6000
Other GPUs that support NVIDIA vGPU software do not support the displaymodeselector tool
and, unless otherwise stated, do not require display mode switching.
Note:
Only Tesla M60 and M6 GPUs support the gpumodeswitch tool. Other GPUs that support
NVIDIA vGPU do not support the gpumodeswitch tool and, unless otherwise stated, 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-460.73.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 Apr 23 18:46:50 2021
+------------------------------------------------------+
| NVIDIA-SMI 460.73.02 Driver Version: 460.73.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.
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
3. Getting the BDF and Domain of a GPU on Red Hat Enterprise Linux KVM
4. Creating an NVIDIA vGPU on Red Hat Enterprise Linux KVM
5. Adding One or More vGPUs to a Red Hat Enterprise Linux KVM VM
6. Setting vGPU Plugin Parameters on Red Hat Enterprise Linux KVM
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.
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 Apr 23 18:46:50 2021
+------------------------------------------------------+
| NVIDIA-SMI 460.73.02 Driver Version: 460.73.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 |
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.
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>
<address domain='0x0000' bus='0x06' slot='0x00' function='0x0'/>
Note: The mdev device file that you create to represent the vGPU does not persist when the
host is rebooted and must be re-created after the host is rebooted. If necessary, 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, by writing a custom script that is executed when the host is
rebooted.
Before you begin, ensure that you have the domain, bus, slot, and function of the GPU on which
you are creating the vGPU. For instructions, see Getting the BDF and Domain of a GPU on Red
Hat Enterprise Linux KVM.
1. If you are using a GPU that supports SR-IOV, such as a GPU based on the NVIDIA Ampere
architecture, enable 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 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 slot:bus:domain.function
slot
bus
domain
function
The slot, bus, domain, 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 function for the GPU with the slot 00, bus 06, domain
0000 function 0.
# /usr/lib/nvidia/sriov-manage -e 00:06:0000.0
2. 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
domain 0000 and PCI device BDF 06:00.0.
# cd /sys/bus/pci/devices/0000\:06\:00.0/mdev_supported_types/
3. Find out which subdirectory of mdev_supported_types contains registration information
for the vGPU type that you want to create.
# grep -l "vgpu-type" nvidia-*/name
vgpu-type
The vGPU type, for example, M10-2Q.
This example shows that the registration information for the M10-2Q vGPU type is
contained in the nvidia-41 subdirectory of mdev_supported_types.
# grep -l "M10-2Q" nvidia-*/name
nvidia-41/name
4. Confirm that you can create an instance of the vGPU type on the physical GPU.
# cat subdirectory/available_instances
subdirectory
The subdirectory that you found in the previous step, for example, nvidia-41.
The number of available instances must be at least 1. If the number is 0, either an instance
of another vGPU type already exists on the physical GPU, or the maximum number of
allowed instances has already been created.
This example shows that four more instances of the M10-2Q vGPU type can be created on
the physical GPU.
# cat nvidia-41/available_instances
4
5. Generate a correctly formatted universally unique identifier (UUID) for the vGPU.
# uuidgen
aa618089-8b16-4d01-a136-25a0f3c73123
6. 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-41.
This example creates an instance of the M10-2Q vGPU type with the UUID
aa618089-8b16-4d01-a136-25a0f3c73123.
# echo "aa618089-8b16-4d01-a136-25a0f3c73123" > nvidia-41/create
An mdev device file for the vGPU is added 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.
7. Confirm that the vGPU was created.
# ls -l /sys/bus/mdev/devices/
total 0
lrwxrwxrwx. 1 root root 0 Nov 24 13:33 aa618089-8b16-4d01-a136-25a0f3c73123 -
> ../../../devices/
pci0000:00/0000:00:03.0/0000:03:00.0/0000:04:09.0/0000:06:00.0/
aa618089-8b16-4d01-a136-25a0f3c73123
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
(VNC) for the vGPU is enabled. The VM to which the vGPU is assigned is started with these
parameters. If parameters are set for multiple vGPUs assigned to the same VM, the VM is
started with the parameters assigned to each vGPU.
For each vGPU for which you want to set plugin parameters, perform this task in a Linux
command shell on the Red Hat Enterprise Linux KVM host.
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 Red Hat
Enterprise Linux KVM.
‣ 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.
# cd `find . -type d -name uuid`
uuid
The UUID of the vGPU, for example, aa618089-8b16-4d01-a136-25a0f3c73123.
3. Write the value 1 to the remove file in the registration information directory for the vGPU
that you want to delete.
# echo "1" > remove
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 Red Hat Enterprise Linux KVM.
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.
# 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
3. Bind the GPU to the nvidia 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 nvidia to the driver_override file in this directory.
# echo nvidia > driver_override
c). Change to the sysfs directory that represents the nvidia kernel module.
# cd /sys/bus/pci/drivers/nvidia
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
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.
‣ /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 Red Hat Enterprise Linux KVM. 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.
Note: When a time-sliced vGPU is created, the content of the available_instances for
all other time-sliced vGPU types on the physical GPU is set to 0. This behavior enforces
the requirement that all time-sliced vGPUs on a physical GPU must be of the same type.
However, this requirement does not apply to MIG-backed vGPUs. Therefore, when a MIG-
backed vGPU is created, available_instances for all other MIG-backed vGPU types on
the physical GPU is not set to 0
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
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.
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.
3. Changing the Default Graphics Type in VMware vSphere 6.5 and Later
4. MIG-backed vGPUs only: Configuring a GPU for MIG-Backed vGPUs
5. Configuring a vSphere VM with NVIDIA vGPU
After configuring a vSphere VM to use NVIDIA vGPU, you can install the NVIDIA vGPU software
graphics driver for your guest OS and license any NVIDIA vGPU software licensed products
that you are using.
‣ 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.
Note: Before proceeding with the vGPU Manager installation 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.
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_6.7_Host_Driver_460.73.02-1OEM.600.0.0.2159203
VIBs Removed: NVIDIA-vGPU-
VMware_ESXi_6.7_Host_Driver_460.32.04-1OEM.600.0.0.2159203
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 Apr 23 17:56:22 2021
+------------------------------------------------------+
| NVIDIA-SMI 460.73.02 Driver Version: 460.73.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:
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.
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.
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.
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.
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 460.73.02 Driver Version: 460.73.02 CUDA Version: 11.2 |
|-------------------------------+----------------------+----------------------+
| 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 |
|====================================================|
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.
+-----------------------------------------------------------------------------+
| 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 460.73.02 Driver Version: 460.73.02 CUDA Version: 11.2 |
|-------------------------------+----------------------+----------------------+
| 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.
‣ 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. These GPUs are supplied with ECC memory enabled.
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.
Note: If you are configuring a GPU for pass-through, do not install the NVIDIA Virtual GPU
Manager.
NVIDIA GPU
Available Pixels Display Resolution Displays per GPU
Architecture
7680×4320 2
Pascal and later 66355200
5120×2880 or lower 4
5120×2880 2
Maxwell 35389440
4096×2160 or lower 4
The following table provides examples of configurations with a mixture of display resolutions.
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.
CAUTION: Do not assign pass-through GPUs using the legacy other-config:pci parameter
setting. This mechanism is not supported alongside the XenCenter UI and xe vgpu
mechanisms, and attempts to use it may lead to undefined results.
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.
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 a Red Hat Enterprise Linux KVM 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.
After configuring a Red Hat Enterprise Linux KVM 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 a Red Hat Enterprise Linux KVM 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.
If your GPU does not support SR-IOV, omit this step.
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 slot:bus:domain.function
slot
bus
domain
function
The slot, bus, domain, and function of the GPU, without the 0x prefix.
This example disables the virtual function for the GPU with the slot 00, bus 06, domain
0000 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.
‣ 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:
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 Settings.
3. From the Hardware menu, choose PCI Devices and click the Edit icon.
4. Select all NVIDIA GPUs and click OK.
5. Reboot the ESXi host.
6. After the ESXi host has booted, right-click the VM and choose Edit Settings.
7. From the New Device menu, choose PCI Device and click Add.
8. On the page that opens, from the New Device drop-down list, select the GPU.
9. Click Reserve all memory and click OK.
10.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
If you are using a Linux OS for which the Wayland display server protocol is enabled by default,
disable it as explained in Disabling the Wayland Display Server Protocol for Red Hat Enterprise
Linux.
1. Copy the NVIDIA vGPU software Linux driver package, for example NVIDIA-
Linux_x86_64-460.73.01-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). Use CTRL-ALT-F1 to switch to a console login prompt.
b). Log in and shut down the display manager:
[nvidia@localhost ~]$ sudo service lightdm stop
3. From a console shell, run the driver installer as the root user.
sudo sh ./NVIDIA-Linux_x86_64-352.47-grid.run
In some instances the installer may fail to detect the installed kernel headers and sources.
In this situation, re-run the installer, specifying the kernel source path with the --kernel-
source-path option:
sudo sh ./NVIDIA-Linux_x86_64-352.47-grid.run \
–kernel-source-path=/usr/src/kernels/3.10.0-229.11.1.el7.x86_64
4. When prompted, accept the option to update the X configuration file (xorg.conf).
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.
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.
Note: For complete information about configuring and using NVIDIA vGPU software licensed
features, including vGPU, refer to Virtual GPU Client Licensing User Guide.
‣ 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, see 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, see 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.
‣ 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.
‣ The destination host has a physical GPU of the same type as the GPU where the vGPU
currently resides.
‣ ECC memory configuration (enabled or disabled) on both the source and destination hosts
must be identical.
‣ The GPU topologies (including NVLink widths) on both the source and destination hosts
must be identical.
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.
machine to another host with very little disruption or downtime. For a VM that is configured
with vGPU, the vGPU is migrated with the VM to an NVIDIA GPU on the other host. The NVIDIA
GPUs on both host machines must be of the same type.
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.
Perform this task in the VMware vSphere web client by using the Migration wizard.
Before migrating a VM configured with vGPU on VMware vSphere, ensure that the following
prerequisites are met:
‣ 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.
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.
Perform this task in the VMware vSphere web client.
‣ 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.
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
Mon Apr 26 19:01:24 2021
+-----------------------------------------------------------------------------+
| NVIDIA-SMI 460.73.02 Driver Version: 460.73.02 CUDA Version: 11.2 |
|-------------------------------+----------------------+----------------------+
| 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 GRID A100X-2-10C On | 00000000:00:08.0 Off | On |
| N/A N/A P0 N/A / N/A | 1058MiB / 10235MiB | N/A Default |
| | | Enabled |
+-------------------------------+----------------------+----------------------+
+-----------------------------------------------------------------------------+
| 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 |
+-----------------------------------------------------------------------------+
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. Set the enable_uvm vGPU plugin parameter to 1.
[root@xenserver ~] xe vgpu-param-set uuid=vgpu-uuid extra_args='enable_uvm=1'
vgpu-uuid
The UUID of the vGPU, which you obtained in the previous step.
This example enables unified memory for the vGPU that has the UUID
d15083f8-5c59-7474-d0cb-fbc3f7284f1b.
[root@xenserver ~] xe vgpu-param-set uuid=d15083f8-5c59-7474-d0cb-fbc3f7284f1b
extra_args='enable_uvm=1'
Set the enable_uvm vGPU plugin parameter for the mdev device file that represents the vGPU
to 1 as explained in Setting vGPU Plugin Parameters on Red Hat Enterprise Linux KVM.
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 that is running Windows or Linux, 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.
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 Apr 23 09:26:18 2021
+-----------------------------------------------------------------------------+
| NVIDIA-SMI 460.73.02 Driver Version: 460.73.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 ~]#
+-------------------------------+--------------------------------+------------+
[root@vgpu ~]#
For each vGPU, the usage statistics in the following table are reported once every second. The
table also shows the name of the column in the command output under which each statistic is
reported.
Statistic Column
3D/Compute sm
Statistic Column
Video decoder dec
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 ~]#
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
‣ GPU ID
‣ vGPU ID
‣ FBC session ID
‣ PID of the process in the VM that created the FBC session
‣ Display ordinal associated with 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
Unknown 4096 2160 0 0 0 0
2 - - - - - - -
- - - - - - -
0 - - - - - - -
- - - - - - -
1 3251634178 1 3984 0 ToSys Disabled Disabled
Unknown 4096 2160 0 0 0 0
2 - - - - - - -
- - - - - - -
0 - - - - - - -
- - - - - - -
1 3251634178 1 3984 0 ToSys Disabled Disabled
Unknown 4096 2160 0 0 0 0
2 - - - - - - -
- - - - - - -
0 - - - - - - -
- - - - - - -
1 3251634178 1 3984 0 ToSys Disabled Disabled
Unknown 4096 2160 0 0 0 0
2 - - - - - - -
- - - - - - -
0 - - - - - - -
- - - - - - -
1 3251634178 1 3984 0 ToSys Disabled Disabled
Unknown 4096 2160 0 0 0 0
2 - - - - - - -
- - - - - - -
0 - - - - - - -
- - - - - - -
1 3251634178 1 3984 0 ToSys Disabled Disabled
Unknown 4096 2160 0 0 0 0
2 - - - - - - -
- - - - - - -
0 - - - - - - -
- - - - - - -
1 3251634178 1 3984 0 ToSys Disabled Disabled
Unknown 4096 2160 0 0 0 0
2 - - - - - - -
- - - - - - -
0 - - - - - - -
- - - - - - -
1 3251634178 1 3984 0 ToSys Disabled Disabled
Blocking 4096 2160 1600 900 25 39964
2 - - - - - - -
- - - - - - -
0 - - - - - - -
- - - - - - -
1 3251634178 1 3984 0 ToSys Disabled Disabled
Blocking 4096 2160 1600 900 25 39964
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 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
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.
To use nvidia-smi to retrieve statistics for resource usage by individual applications running
in the VM, run the following command:
nvidia-smi pmon
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
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
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.
‣ 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
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. Set the RmPVMRL registry key to the value that sets the GPU scheduling policy and the
length of the time slice that you want.
‣ 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.
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. Use the lspci command to obtain the PCI domain and bus/device/function (BDF) of each
GPU for which you want to change the scheduling behavior.
‣ 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...]"
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"
Confirm that the scheduling behavior was changed as required as explained in Getting the
Current Time-Sliced vGPU Scheduling Behavior for All GPUs.
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. Unset the RmPVMRL registry key.
‣ 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-460.73.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-460.73.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-460.73.02.x86_64 conflicts with file from package NVIDIA-
vGPU-xenserver-8.2-460.32.04.x86_64
file /usr/lib/libnvidia-ml.so from install of NVIDIA-vGPU-NVIDIA-vGPU-
CitrixHypervisor-8.2-460.73.02.x86_64 conflicts with file from package NVIDIA-
vGPU-xenserver-8.2-460.32.04.x86_64
...
This example runs nvidia-bug-report.sh on Citrix Hypervisor, but the procedure is the
same on Red Hat Enterprise Linux KVM, RHV, or VMware vSphere ESXi.
[root@xenserver ~]# nvidia-bug-report.sh
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
A100-40C 40960 1 1 4096×21602 1
Workloads
Training
A100-20C 20480 2 2 4096×21602 1
Workloads
Training
A100-10C 10240 4 4 4096×21602 1
Workloads
Training
A100-8C 8192 5 5 4096×21602 1
Workloads
Inference
A100-5C 5120 8 8 4096×21602 1
Workloads
Inference
A100-4C 4096 10 10 4096×21602 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
A100X-40C 40960 1 1 4096×21602 1
Workloads
Training
A100X-20C 20480 2 2 4096×21602 1
Workloads
Training
A100X-10C 10240 4 4 4096×21602 1
Workloads
Training
A100X-8C 8192 5 5 4096×21602 1
Workloads
Inference
A100X-5C 5120 8 8 4096×21602 1
Workloads
Inference
A100X-4C 4096 10 10 4096×21602 1
Workloads
This GPU supports MIG-backed virtual GPUs and time-sliced virtual GPUs.
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
A100DX-80C 81920 1 1 4096×21602 1
Workloads
Training
A100DX-40C 40960 2 2 4096×21602 1
Workloads
Training
A100DX-20C 20480 4 4 4096×21602 1
Workloads
Inference
A100DX-16C 16384 5 5 4096×21602 1
Workloads
Training
A100DX-10C 10240 8 8 4096×21602 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
A100DX-8C 8192 10 10 4096×21602 1
Workloads
Inference
A100DX-4C 4096 20 20 4096×21602 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 or
Workstations 4
lower
7680×4320 2
Virtual
A40-24Q 24576 2 2 66355200 5120×2880 or
Workstations 4
lower
7680×4320 2
Virtual
A40-16Q 16384 3 3 66355200 5120×2880 or
Workstations 4
lower
7680×4320 2
Virtual
A40-12Q 12288 4 4 66355200 5120×2880 or
Workstations 4
lower
Virtual
A40-8Q 8192 6 6 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 or
4
lower
7680×4320 1
Virtual
A40-6Q 6144 8 8 58982400 5120×2880 or
Workstations 4
lower
7680×4320 1
Virtual
A40-4Q 4096 12 12 58982400 5120×2880 or
Workstations 4
lower
7680×4320 1
Virtual 5120×2880 2
A40-3Q 3072 16 16 35389440
Workstations 4096×2160 or
4
lower
7680×4320 1
Virtual 5120×2880 2
A40-2Q 2048 24 24 35389440
Workstations 4096×2160 or
4
lower
5120×2880 1
4096×2160 2
Virtual 9
A40-1Q 1024 32 32 17694720 3840×2160 2
Workstations
2560×1600 or
4
lower
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
5120×2880 1
4096×2160 2
Virtual
A40-2B 2048 24 24 17694720 3840×2160 2
Desktops
2560×1600 or
4
lower
5120×2880 1
4096×2160 1
Virtual
A40-1B 1024 32 32 16384000 3840×2160 1
Desktops
2560×1600 or
45
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
A40-48C 49152 1 1 4096×21602 1
Workloads
Training
A40-24C 24576 2 2 4096×21602 1
Workloads
Training
A40-16C 16384 3 3 4096×21602 1
Workloads
Training
A40-12C 12288 4 4 4096×21602 1
Workloads
Training
A40-8C 8192 6 6 4096×21602 1
Workloads
Training
A40-6C 6144 8 8 4096×21602 1
Workloads
Inference
A40-4C 4096 83 12 4096×21602 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
A40-48A 49152 1 1 1280×1024 1
Applications
Virtual
A40-24A 24576 2 2 1280×1024 1
Applications
Virtual
A40-16A 16384 3 3 1280×1024 1
Applications
Virtual
A40-12A 12288 4 4 1280×1024 1
Applications
Virtual
A40-8A 8192 6 6 1280×1024 1
Applications
Virtual
A40-6A 6144 8 8 1280×1024 1
Applications
Virtual
A40-4A 4096 12 12 1280×1024 1
Applications
Virtual
A40-3A 3072 16 16 1280×1024 1
Applications
Virtual
A40-2A 2048 24 24 1280×1024 1
Applications
Virtual
A40-1A 1024 329 32 1280×1024 1
Applications
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
A10-24Q 24576 1 1 66355200 5120×2880 or
Workstations 4
lower
7680×4320 2
Virtual
A10-12Q 12288 2 2 66355200 5120×2880 or
Workstations 4
lower
7680×4320 2
Virtual
A10-8Q 8192 3 3 66355200 5120×2880 or
Workstations 4
lower
7680×4320 1
Virtual
A10-6Q 6144 4 4 58982400 5120×2880 or
Workstations 4
lower
7680×4320 1
Virtual
A10-4Q 4096 6 6 58982400 5120×2880 or
Workstations 4
lower
7680×4320 1
Virtual 5120×2880 2
A10-3Q 3072 8 8 35389440
Workstations 4096×2160 or
4
lower
7680×4320 1
Virtual 5120×2880 2
A10-2Q 2048 12 12 35389440
Workstations 4096×2160 or
4
lower
5120×2880 1
4096×2160 2
Virtual
A10-1Q 1024 24 24 17694720 3840×2160 2
Workstations
2560×1600 or
4
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 or
4
lower
5120×2880 1
4096×2160 1
Virtual
A10-1B 1024 24 24 16384000 3840×2160 1
Desktops
2560×1600 or
45
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
A10-24C 24576 1 1 4096×21602 1
Workloads
Training
A10-12C 12288 2 2 4096×21602 1
Workloads
Training
A10-8C 8192 3 3 4096×21602 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
A10-6C 6144 4 4 4096×21602 1
Workloads
Inference
A10-4C 4096 6 6 4096×21602 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
A10-24A 24576 1 1 1280×1024 1
Applications
Virtual
A10-12A 12288 2 2 1280×1024 1
Applications
Virtual
A10-8A 8192 3 3 1280×1024 1
Applications
Virtual
A10-6A 6144 4 4 1280×1024 1
Applications
Virtual
A10-4A 4096 6 6 1280×1024 1
Applications
Virtual
A10-3A 3072 8 8 1280×1024 1
Applications
Virtual
A10-2A 2048 12 12 1280×1024 1
Applications
Virtual
A10-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
RTXA6000-48Q 49152 1 1 66355200 5120×2880 or
Workstations 4
lower
7680×4320 2
Virtual
RTXA6000-24Q 24576 2 2 66355200 5120×2880 or
Workstations 4
lower
7680×4320 2
Virtual
RTXA6000-16Q 16384 3 3 66355200 5120×2880 or
Workstations 4
lower
7680×4320 2
Virtual
RTXA6000-12Q 12288 4 4 66355200 5120×2880 or
Workstations 4
lower
7680×4320 2
Virtual
RTXA6000-8Q 8192 6 6 66355200 5120×2880 or
Workstations 4
lower
7680×4320 1
Virtual
RTXA6000-6Q 6144 8 8 58982400 5120×2880 or
Workstations 4
lower
7680×4320 1
Virtual
RTXA6000-4Q 4096 12 12 58982400 5120×2880 or
Workstations 4
lower
7680×4320 1
Virtual 5120×2880 2
RTXA6000-3Q 3072 16 16 35389440
Workstations 4096×2160 or
4
lower
Virtual 7680×4320 1
RTXA6000-2Q 2048 24 24 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 or
4
lower
5120×2880 1
4096×2160 2
Virtual 9
RTXA6000-1Q 1024 32 32 17694720 3840×2160 2
Workstations
2560×1600 or
4
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
RTXA6000-2B 2048 24 24 17694720 3840×2160 2
Desktops
2560×1600 or
4
lower
5120×2880 1
4096×2160 1
Virtual
RTXA6000-1B 1024 32 32 16384000 3840×2160 1
Desktops
2560×1600 or
45
lower
8
The maximum vGPUs per GPU is limited to 32.
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
RTXA6000-48C 49152 1 1 4096×21602 1
Workloads
Training
RTXA6000-24C 24576 2 2 4096×21602 1
Workloads
Training
RTXA6000-16C 16384 3 3 4096×21602 1
Workloads
Training
RTXA6000-12C 12288 4 4 4096×21602 1
Workloads
Training
RTXA6000-8C 8192 6 6 4096×21602 1
Workloads
Training
RTXA6000-6C 6144 8 8 4096×21602 1
Workloads
Inference
RTXA6000-4C 4096 83 12 4096×21602 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
RTXA6000-48A 49152 1 1 1280×1024 1
Applications
Virtual
RTXA6000-24A 24576 2 2 1280×1024 1
Applications
Virtual
RTXA6000-16A 16384 3 3 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
RTXA6000-12A 12288 4 4 1280×1024 1
Applications
Virtual
RTXA6000-8A 8192 6 6 1280×1024 1
Applications
Virtual
RTXA6000-6A 6144 8 8 1280×1024 1
Applications
Virtual
RTXA6000-4A 4096 12 12 1280×1024 1
Applications
Virtual
RTXA6000-3A 3072 16 16 1280×1024 1
Applications
Virtual
RTXA6000-2A 2048 24 24 1280×1024 1
Applications
Virtual
RTXA6000-1A 1024 329 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 or
Workstations 4
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
RTXA5000-12Q 12288 2 2 66355200 5120×2880 or
Workstations 4
lower
7680×4320 2
Virtual
RTXA5000-8Q 8192 3 3 66355200 5120×2880 or
Workstations 4
lower
7680×4320 1
Virtual
RTXA5000-6Q 6144 4 4 58982400 5120×2880 or
Workstations 4
lower
7680×4320 1
Virtual
RTXA5000-4Q 4096 6 6 58982400 5120×2880 or
Workstations 4
lower
7680×4320 1
Virtual 5120×2880 2
RTXA5000-3Q 3072 8 8 35389440
Workstations 4096×2160 or
4
lower
7680×4320 1
Virtual 5120×2880 2
RTXA5000-2Q 2048 12 12 35389440
Workstations 4096×2160 or
4
lower
5120×2880 1
4096×2160 2
Virtual
RTXA5000-1Q 1024 24 24 17694720 3840×2160 2
Workstations
2560×1600 or
4
lower
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
RTXA5000-2B 2048 12 12 17694720 3840×2160 2
Desktops
2560×1600 or
4
lower
5120×2880 1
4096×2160 1
Virtual
RTXA5000-1B 1024 24 24 16384000 3840×2160 1
Desktops
2560×1600 or
45
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
RTXA5000-24C 24576 1 1 4096×21602 1
Workloads
Training
RTXA5000-12C 12288 2 2 4096×21602 1
Workloads
Training
RTXA5000-8C 8192 3 3 4096×21602 1
Workloads
Training
RTXA5000-6C 6144 4 4 4096×21602 1
Workloads
Inference
RTXA5000-4C 4096 6 6 4096×21602 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
RTXA5000-24A 24576 1 1 1280×1024 1
Applications
Virtual
RTXA5000-12A 12288 2 2 1280×1024 1
Applications
Virtual
RTXA5000-8A 8192 3 3 1280×1024 1
Applications
Virtual
RTXA5000-6A 6144 4 4 1280×1024 1
Applications
Virtual
RTXA5000-4A 4096 6 6 1280×1024 1
Applications
Virtual
RTXA5000-3A 3072 8 8 1280×1024 1
Applications
Virtual
RTXA5000-2A 2048 12 12 1280×1024 1
Applications
Virtual
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
5120×2880 2
Virtual
M60-8Q 8192 1 2 35389440 4096×2160 or
Workstations 4
lower
5120×2880 2
Virtual
M60-4Q 4096 2 4 35389440 4096×2160 or
Workstations 4
lower
5120×2880 2
Virtual
M60-2Q 2048 4 8 35389440 4096×2160 or
Workstations 4
lower
5120×2880 1
Virtual
4096×2160 2
Desktops,
M60-1Q 1024 8 16 17694720 3840×2160 2
Virtual
Workstations 2560×1600 or
4
lower
Virtual
Desktops,
M60-0Q 512 16 32 8192000 2560×1600 21
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
Virtual 5120×2880 1
M60-2B 2048 4 8 17694720
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 or
4
lower
5120×2880 1
4096×2160 2
4
Virtual
M60-2B4 2048 4 8 17694720 3840×2160 2
Desktops
2560×1600 or
4
lower
5120×2880 1
4096×2160 1
Virtual
M60-1B 1024 8 16 16384000 3840×2160 1
Desktops
2560×1600 or
45
lower
5120×2880 1
4096×2160 1
4
Virtual
M60-1B4 1024 8 16 16384000 3840×2160 1
Desktops
2560×1600 or
45
lower
Virtual
M60-0B 512 16 32 8192000 2560×1600 21
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
M60-8A 8192 1 2 1280×10246 16
Applications
Virtual
M60-4A 4096 2 4 1280×10246 16
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
M60-2A 2048 4 8 1280×10246 16
Applications
Virtual
M60-1A 1024 8 16 1280×10246 16
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 or
Workstations 4
lower
5120×2880 2
Virtual
M10-4Q 4096 2 8 35389440 4096×2160 or
Workstations 4
lower
5120×2880 2
Virtual
M10-2Q 2048 4 16 35389440 4096×2160 or
Workstations 4
lower
5120×2880 1
Virtual
4096×2160 2
Desktops,
M10-1Q 1024 8 32 17694720 3840×2160 2
Virtual
Workstations 2560×1600 or
4
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
Desktops,
M10-0Q 512 16 64 8192000 2560×1600 21
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 or
4
lower
5120×2880 1
4096×2160 2
4
Virtual
M10-2B4 2048 4 16 17694720 3840×2160 2
Desktops
2560×1600 or
4
lower
5120×2880 1
4096×2160 1
Virtual
M10-1B 1024 8 32 16384000 3840×2160 1
Desktops
2560×1600 or
45
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
4096×2160 1
Virtual 3840×2160 1
Desktops 2560×1600 or
45
lower
Virtual
M10-0B 512 16 64 8192000 2560×1600 21
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
M10-8A 8192 1 4 1280×10246 16
Applications
Virtual
M10-4A 4096 2 8 1280×10246 16
Applications
Virtual
M10-2A 2048 4 16 1280×10246 16
Applications
Virtual
M10-1A 1024 8 32 1280×10246 16
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
M6-8Q 8192 1 1 35389440 4096×2160 or
Workstations 4
lower
5120×2880 2
Virtual
M6-4Q 4096 2 2 35389440 4096×2160 or
Workstations 4
lower
5120×2880 2
Virtual
M6-2Q 2048 4 4 35389440 4096×2160 or
Workstations 4
lower
5120×2880 1
Virtual
4096×2160 2
Desktops,
M6-1Q 1024 8 8 17694720 3840×2160 2
Virtual
Workstations 2560×1600 or
4
lower
Virtual
Desktops,
M6-0Q 512 16 16 8192000 2560×1600 21
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
Virtual 5120×2880 1
M6-2B 2048 4 4 17694720
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 or
4
lower
5120×2880 1
4096×2160 2
4
Virtual
M6-2B4 2048 4 4 17694720 3840×2160 2
Desktops
2560×1600 or
4
lower
5120×2880 1
4096×2160 1
Virtual
M6-1B 1024 8 8 16384000 3840×2160 1
Desktops
2560×1600 or
45
lower
5120×2880 1
4096×2160 1
4
Virtual
M6-1B4 1024 8 8 16384000 3840×2160 1
Desktops
2560×1600 or
45
lower
Virtual
M6-0B 512 16 16 8192000 2560×1600 21
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
M6-8A 8192 1 1 1280×10246 16
Applications
Virtual
M6-4A 4096 2 2 1280×10246 16
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
M6-2A 2048 4 4 1280×10246 16
Applications
Virtual
M6-1A 1024 8 8 1280×10246 16
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 or
Workstations 4
lower
7680×4320 1
Virtual
P100C-6Q 6144 2 2 58982400 5120×2880 or
Workstations 4
lower
7680×4320 1
Virtual
P100C-4Q 4096 3 3 58982400 5120×2880 or
Workstations 4
lower
7680×4320 1
Virtual 5120×2880 2
P100C-2Q 2048 6 6 35389440
Workstations 4096×2160 or
4
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
4096×2160 2
Desktops,
P100C-1Q 1024 12 12 17694720 3840×2160 2
Virtual
Workstations 2560×1600 or
4
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 or
4
lower
5120×2880 1
4096×2160 2
4
Virtual
P100C-2B4 2048 6 6 17694720 3840×2160 2
Desktops
2560×1600 or
4
lower
5120×2880 1
4096×2160 1
Virtual
P100C-1B 1024 12 12 16384000 3840×2160 1
Desktops
2560×1600 or
45
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
4
Virtual
P100C-1B4 1024 12 12 16384000 3840×2160 1
Desktops
2560×1600 or
45
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
P100C-12C 12288 1 1 4096×21602 1
Workloads
Training
P100C-6C 6144 2 2 4096×21602 1
Workloads
Inference
P100C-4C 4096 3 3 4096×21602 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
P100C-12A 12288 1 1 1280×10246 16
Applications
Virtual
P100C-6A 6144 2 2 1280×10246 16
Applications
Virtual
P100C-4A 4096 3 3 1280×10246 16
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
P100C-2A 2048 6 6 1280×10246 16
Applications
Virtual
P100C-1A 1024 12 12 1280×10246 16
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 or
Workstations 4
lower
7680×4320 2
Virtual
P100-8Q 8192 2 2 66355200 5120×2880 or
Workstations 4
lower
7680×4320 1
Virtual
P100-4Q 4096 4 4 58982400 5120×2880 or
Workstations 4
lower
7680×4320 1
Virtual 5120×2880 2
P100-2Q 2048 8 8 35389440
Workstations 4096×2160 or
4
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
4096×2160 2
Desktops,
P100-1Q 1024 16 16 17694720 3840×2160 2
Virtual
Workstations 2560×1600 or
4
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 or
4
lower
5120×2880 1
4096×2160 2
4
Virtual
P100-2B4 2048 8 8 17694720 3840×2160 2
Desktops
2560×1600 or
4
lower
5120×2880 1
4096×2160 1
Virtual
P100-1B 1024 16 16 16384000 3840×2160 1
Desktops
2560×1600 or
45
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
4
Virtual
P100-1B4 1024 16 16 16384000 3840×2160 1
Desktops
2560×1600 or
45
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
P100-16C 16384 1 1 4096×21602 1
Workloads
Training
P100-8C 8192 2 2 4096×21602 1
Workloads
Inference
P100-4C 4096 4 4 4096×21602 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
P100-16A 16384 1 1 1280×10246 16
Applications
Virtual
P100-8A 8192 2 2 1280×10246 16
Applications
Virtual
P100-4A 4096 4 4 1280×10246 16
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
P100-2A 2048 8 8 1280×10246 16
Applications
Virtual
P100-1A 1024 16 16 1280×10246 16
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 or
Workstations 4
lower
7680×4320 2
Virtual
P100X-8Q 8192 2 2 66355200 5120×2880 or
Workstations 4
lower
7680×4320 1
Virtual
P100X-4Q 4096 4 4 58982400 5120×2880 or
Workstations 4
lower
7680×4320 1
Virtual 5120×2880 2
P100X-2Q 2048 8 8 35389440
Workstations 4096×2160 or
4
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
4096×2160 2
Desktops,
P100X-1Q 1024 16 16 17694720 3840×2160 2
Virtual
Workstations 2560×1600 or
4
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 or
4
lower
5120×2880 1
4096×2160 2
4
Virtual
P100X-2B4 2048 8 8 17694720 3840×2160 2
Desktops
2560×1600 or
4
lower
5120×2880 1
4096×2160 1
Virtual
P100X-1B 1024 16 16 16384000 3840×2160 1
Desktops
2560×1600 or
45
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
4
Virtual
P100X-1B4 1024 16 16 16384000 3840×2160 1
Desktops
2560×1600 or
45
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
P100X-16C 16384 1 1 4096×21602 1
Workloads
Training
P100X-8C 8192 2 2 4096×21602 1
Workloads
Inference
P100X-4C 4096 4 4 4096×21602 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
P100X-16A 16384 1 1 1280×10246 16
Applications
Virtual
P100X-8A 8192 2 2 1280×10246 16
Applications
Virtual
P100X-4A 4096 4 4 1280×10246 16
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
P100X-2A 2048 8 8 1280×10246 16
Applications
Virtual
P100X-1A 1024 16 16 1280×10246 16
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 or
Workstations 4
lower
7680×4320 2
Virtual
P40-12Q 12288 2 2 66355200 5120×2880 or
Workstations 4
lower
7680×4320 2
Virtual
P40-8Q 8192 3 3 66355200 5120×2880 or
Workstations 4
lower
7680×4320 1
Virtual
P40-6Q 6144 4 4 58982400 5120×2880 or
Workstations 4
lower
Virtual
P40-4Q 4096 6 6 58982400 7680×4320 1
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 or
4
lower
7680×4320 1
Virtual 5120×2880 2
P40-3Q 3072 8 8 35389440
Workstations 4096×2160 or
4
lower
7680×4320 1
Virtual 5120×2880 2
P40-2Q 2048 12 12 35389440
Workstations 4096×2160 or
4
lower
5120×2880 1
Virtual
4096×2160 2
Desktops,
P40-1Q 1024 24 24 17694720 3840×2160 2
Virtual
Workstations 2560×1600 or
4
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 or
4
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
P40-2B4 2048 12 12 17694720 3840×2160 2
Desktops
2560×1600 or
4
lower
5120×2880 1
4096×2160 1
Virtual
P40-1B 1024 24 24 16384000 3840×2160 1
Desktops
2560×1600 or
45
lower
5120×2880 1
4096×2160 1
Virtual
P40-1B44 1024 24 24 16384000 3840×2160 1
Desktops
2560×1600 or
45
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
P40-24C 24576 1 1 4096×21602 1
Workloads
Training
P40-12C 12288 2 2 4096×21602 1
Workloads
Training
P40-8C 8192 3 3 4096×21602 1
Workloads
Training
P40-6C 6144 4 4 4096×21602 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
P40-4C 4096 6 6 4096×21602 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
P40-24A 24576 1 1 1280×10246 16
Applications
Virtual
P40-12A 12288 2 2 1280×10246 16
Applications
Virtual
P40-8A 8192 3 3 1280×10246 16
Applications
Virtual
P40-6A 6144 4 4 1280×10246 16
Applications
Virtual
P40-4A 4096 6 6 1280×10246 16
Applications
Virtual
P40-3A 3072 8 8 1280×10246 16
Applications
Virtual
P40-2A 2048 12 12 1280×10246 16
Applications
Virtual
P40-1A 1024 24 24 1280×10246 16
Applications
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
P6-16Q 16384 1 1 66355200 5120×2880 or
Workstations 4
lower
7680×4320 2
Virtual
P6-8Q 8192 2 2 66355200 5120×2880 or
Workstations 4
lower
7680×4320 1
Virtual
P6-4Q 4096 4 4 58982400 5120×2880 or
Workstations 4
lower
7680×4320 1
Virtual 5120×2880 2
P6-2Q 2048 8 8 35389440
Workstations 4096×2160 or
4
lower
5120×2880 1
Virtual
4096×2160 2
Desktops,
P6-1Q 1024 16 16 17694720 3840×2160 2
Virtual
Workstations 2560×1600 or
4
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
P6-2B 2048 8 8 17694720 3840×2160 2
Desktops
2560×1600 or
4
lower
5120×2880 1
4096×2160 2
Virtual
P6-2B44 2048 8 8 17694720 3840×2160 2
Desktops
2560×1600 or
4
lower
5120×2880 1
4096×2160 1
Virtual
P6-1B 1024 16 16 16384000 3840×2160 1
Desktops
2560×1600 or
45
lower
5120×2880 1
4096×2160 1
Virtual
P6-1B44 1024 16 16 16384000 3840×2160 1
Desktops
2560×1600 or
45
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
P6-16C 16384 1 1 4096×21602 1
Workloads
Training
P6-8C 8192 2 2 4096×21602 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
P6-4C 4096 4 4 4096×21602 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
P6-16A 16384 1 1 1280×10246 16
Applications
Virtual
P6-8A 8192 2 2 1280×10246 16
Applications
Virtual
P6-4A 4096 4 4 1280×10246 16
Applications
Virtual
P6-2A 2048 8 8 1280×10246 16
Applications
Virtual
P6-1A 1024 16 16 1280×10246 16
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
P4-8Q 8192 1 1 66355200 5120×2880 or
Workstations 4
lower
7680×4320 1
Virtual
P4-4Q 4096 2 2 58982400 5120×2880 or
Workstations 4
lower
7680×4320 1
Virtual 5120×2880 2
P4-2Q 2048 4 4 35389440
Workstations 4096×2160 or
4
lower
5120×2880 1
Virtual
4096×2160 2
Desktops,
P4-1Q 1024 8 8 17694720 3840×2160 2
Virtual
Workstations 2560×1600 or
4
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
P4-2B 2048 4 4 17694720 3840×2160 2
Desktops
2560×1600 or
4
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
P4-2B4 2048 4 4 17694720 3840×2160 2
Desktops
2560×1600 or
4
lower
5120×2880 1
4096×2160 1
Virtual
P4-1B 1024 8 8 16384000 3840×2160 1
Desktops
2560×1600 or
45
lower
5120×2880 1
4096×2160 1
Virtual
P4-1B44 1024 8 8 16384000 3840×2160 1
Desktops
2560×1600 or
45
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
P4-8C 8192 1 1 4096×21602 1
Workloads
Inference
P4-4C 4096 2 2 4096×21602 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
P4-8A 8192 1 1 1280×10246 16
Applications
Virtual
P4-4A 4096 2 2 1280×10246 16
Applications
Virtual
P4-2A 2048 4 4 1280×10246 16
Applications
Virtual
P4-1A 1024 8 8 1280×10246 16
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 or
Workstations 4
lower
7680×4320 2
Virtual
T4-8Q 8192 2 2 66355200 5120×2880 or
Workstations 4
lower
7680×4320 1
Virtual
T4-4Q 4096 4 4 58982400 5120×2880 or
Workstations 4
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
T4-2Q 2048 8 8 35389440
Workstations 4096×2160 or
4
lower
5120×2880 1
Virtual
4096×2160 2
Desktops,
T4-1Q 1024 16 16 17694720 3840×2160 2
Virtual
Workstations 2560×1600 or
4
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 or
4
lower
5120×2880 1
4096×2160 2
4
Virtual
T4-2B4 2048 8 8 17694720 3840×2160 2
Desktops
2560×1600 or
4
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
T4-1B 1024 16 16 16384000 3840×2160 1
Desktops
2560×1600 or
45
lower
5120×2880 1
4096×2160 1
Virtual
T4-1B44 1024 16 16 16384000 3840×2160 1
Desktops
2560×1600 or
45
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
T4-16C 16384 1 1 4096×21602 1
Workloads
Training
T4-8C 8192 2 2 4096×21602 1
Workloads
Inference
T4-4C 4096 4 4 4096×21602 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
T4-16A 16384 1 1 1280×10246 16
Applications
Virtual
T4-8A 8192 2 2 1280×10246 16
Applications
Virtual
T4-4A 4096 4 4 1280×10246 16
Applications
Virtual
T4-2A 2048 8 8 1280×10246 16
Applications
Virtual
T4-1A 1024 16 16 1280×10246 16
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 or
Workstations 4
lower
7680×4320 2
Virtual
V100X-8Q 8192 2 2 66355200 5120×2880 or
Workstations 4
lower
Virtual
V100X-4Q 4096 4 4 58982400 7680×4320 1
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 or
4
lower
7680×4320 1
Virtual 5120×2880 2
V100X-2Q 2048 8 8 35389440
Workstations 4096×2160 or
4
lower
5120×2880 1
Virtual
4096×2160 2
Desktops,
V100X-1Q 1024 16 16 17694720 3840×2160 2
Virtual
Workstations 2560×1600 or
4
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 or
4
lower
5120×2880 1
Virtual
V100X-2B44 2048 8 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 or
4
lower
5120×2880 1
4096×2160 1
Virtual
V100X-1B 1024 16 16 16384000 3840×2160 1
Desktops
2560×1600 or
45
lower
5120×2880 1
4096×2160 1
4
Virtual
V100X-1B4 1024 16 16 16384000 3840×2160 1
Desktops
2560×1600 or
45
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
V100X-16C 16384 1 1 4096×21602 1
Workloads
Training
V100X-8C 8192 2 2 4096×21602 1
Workloads
Inference
V100X-4C 4096 4 4 4096×21602 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
V100X-16A 16384 1 1 1280×10246 16
Applications
Virtual
V100X-8A 8192 2 2 1280×10246 16
Applications
Virtual
V100X-4A 4096 4 4 1280×10246 16
Applications
Virtual
V100X-2A 2048 8 8 1280×10246 16
Applications
Virtual
V100X-1A 1024 16 16 1280×10246 16
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 or
Workstations 4
lower
7680×4320 2
Virtual
V100DX-16Q 16384 2 2 66355200 5120×2880 or
Workstations 4
lower
Virtual
V100DX-8Q 8192 4 4 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 or
4
lower
7680×4320 1
Virtual
V100DX-4Q 4096 8 8 58982400 5120×2880 or
Workstations 4
lower
7680×4320 1
Virtual 5120×2880 2
V100DX-2Q 2048 16 16 35389440
Workstations 4096×2160 or
4
lower
5120×2880 1
Virtual
4096×2160 2
Desktops,
V100DX-1Q 1024 32 32 17694720 3840×2160 2
Virtual
Workstations 2560×1600 or
4
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
V100DX-2B 2048 16 16 17694720 3840×2160 2
Desktops
2560×1600 or
4
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
4096×2160 2
Virtual 3840×2160 2
Desktops 2560×1600 or
4
lower
5120×2880 1
4096×2160 1
Virtual
V100DX-1B 1024 32 32 16384000 3840×2160 1
Desktops
2560×1600 or
45
lower
5120×2880 1
4096×2160 1
4
Virtual
V100DX-1B4 1024 32 32 16384000 3840×2160 1
Desktops
2560×1600 or
45
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
V100DX-32C 32768 1 1 4096×21602 1
Workloads
Training
V100DX-16C 16384 2 2 4096×21602 1
Workloads
Training
V100DX-8C 8192 4 4 4096×21602 1
Workloads
Inference
V100DX-4C 4096 8 8 4096×21602 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
V100DX-32A 32768 1 1 1280×10246 16
Applications
Virtual
V100DX-16A 16384 2 2 1280×10246 16
Applications
Virtual
V100DX-8A 8192 4 4 1280×10246 16
Applications
Virtual
V100DX-4A 4096 8 8 1280×10246 16
Applications
Virtual
V100DX-2A 2048 16 16 1280×10246 16
Applications
Virtual
V100DX-1A 1024 32 32 1280×10246 16
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
V100-16Q 16384 1 1 66355200 5120×2880 or
Workstations 4
lower
Virtual
V100-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 or
4
lower
7680×4320 1
Virtual
V100-4Q 4096 4 4 58982400 5120×2880 or
Workstations 4
lower
7680×4320 1
Virtual 5120×2880 2
V100-2Q 2048 8 8 35389440
Workstations 4096×2160 or
4
lower
5120×2880 1
Virtual
4096×2160 2
Desktops,
V100-1Q 1024 16 16 17694720 3840×2160 2
Virtual
Workstations 2560×1600 or
4
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 or
4
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
4096×2160 2
Virtual 3840×2160 2
Desktops 2560×1600 or
4
lower
5120×2880 1
4096×2160 1
Virtual
V100-1B 1024 16 16 16384000 3840×2160 1
Desktops
2560×1600 or
45
lower
5120×2880 1
4096×2160 1
4
Virtual
V100-1B4 1024 16 16 16384000 3840×2160 1
Desktops
2560×1600 or
45
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
V100-16C 16384 1 1 4096×21602 1
Workloads
Training
V100-8C 8192 2 2 4096×21602 1
Workloads
Inference
V100-4C 4096 4 4 4096×21602 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
V100-16A 16384 1 1 1280×10246 16
Applications
Virtual
V100-8A 8192 2 2 1280×10246 16
Applications
Virtual
V100-4A 4096 4 4 1280×10246 16
Applications
Virtual
V100-2A 2048 8 8 1280×10246 16
Applications
Virtual
V100-1A 1024 16 16 1280×10246 16
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 or
Workstations 4
lower
7680×4320 2
Virtual
V100D-16Q 16384 2 2 66355200 5120×2880 or
Workstations 4
lower
Virtual
V100D-8Q 8192 4 4 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 or
4
lower
7680×4320 1
Virtual
V100D-4Q 4096 8 8 58982400 5120×2880 or
Workstations 4
lower
7680×4320 1
Virtual 5120×2880 2
V100D-2Q 2048 16 16 35389440
Workstations 4096×2160 or
4
lower
5120×2880 1
Virtual
4096×2160 2
Desktops,
V100D-1Q 1024 32 32 17694720 3840×2160 2
Virtual
Workstations 2560×1600 or
4
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 or
4
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
4096×2160 2
Virtual 3840×2160 2
Desktops 2560×1600 or
4
lower
5120×2880 1
4096×2160 1
Virtual
V100D-1B 1024 32 32 16384000 3840×2160 1
Desktops
2560×1600 or
45
lower
5120×2880 1
4096×2160 1
4
Virtual
V100D-1B4 1024 32 32 16384000 3840×2160 1
Desktops
2560×1600 or
45
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
V100D-32C 32768 1 1 4096×21602 1
Workloads
Training
V100D-16C 16384 2 2 4096×21602 1
Workloads
Training
V100D-8C 8192 4 4 4096×21602 1
Workloads
Inference
V100D-4C 4096 8 8 4096×21602 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
V100D-32A 32768 1 1 1280×10246 16
Applications
Virtual
V100D-16A 16384 2 2 1280×10246 16
Applications
Virtual
V100D-8A 8192 4 4 1280×10246 16
Applications
Virtual
V100D-4A 4096 8 8 1280×10246 16
Applications
Virtual
V100D-2A 2048 16 16 1280×10246 16
Applications
Virtual
V100D-1A 1024 32 32 1280×10246 16
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
V100S-32Q 32768 1 1 66355200 5120×2880 or
Workstations 4
lower
Virtual
V100S-16Q 16384 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 or
4
lower
7680×4320 2
Virtual
V100S-8Q 8192 4 4 66355200 5120×2880 or
Workstations 4
lower
7680×4320 1
Virtual
V100S-4Q 4096 8 8 58982400 5120×2880 or
Workstations 4
lower
7680×4320 1
Virtual 5120×2880 2
V100S-2Q 2048 16 16 35389440
Workstations 4096×2160 or
4
lower
5120×2880 1
Virtual
4096×2160 2
Desktops,
V100S-1Q 1024 32 32 17694720 3840×2160 2
Virtual
Workstations 2560×1600 or
4
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
V100S-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 or
4
lower
5120×2880 1
4096×2160 1
Virtual
V100S-1B 1024 32 32 16384000 3840×2160 1
Desktops
2560×1600 or
45
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
V100S-32C 32768 1 1 4096×21602 1
Workloads
Training
V100S-16C 16384 2 2 4096×21602 1
Workloads
Training
V100S-8C 8192 4 4 4096×21602 1
Workloads
Inference
V100S-4C 4096 8 8 4096×21602 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
V100S-32A 32768 1 1 1280×10246 16
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
V100S-16A 16384 2 2 1280×10246 16
Applications
Virtual
V100S-8A 8192 4 4 1280×10246 16
Applications
Virtual
V100S-4A 4096 8 8 1280×10246 16
Applications
Virtual
V100S-2A 2048 16 16 1280×10246 16
Applications
Virtual
V100S-1A 1024 32 32 1280×10246 16
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 or
Workstations 4
lower
7680×4320 2
Virtual
V100L-8Q 8192 2 2 66355200 5120×2880 or
Workstations 4
lower
Virtual
V100L-4Q 4096 4 4 58982400 7680×4320 1
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 or
4
lower
7680×4320 1
Virtual 5120×2880 2
V100L-2Q 2048 8 8 35389440
Workstations 4096×2160 or
4
lower
5120×2880 1
Virtual
4096×2160 2
Desktops,
V100L-1Q 1024 16 16 17694720 3840×2160 2
Virtual
Workstations 2560×1600 or
4
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 or
4
lower
5120×2880 1
Virtual
V100L-2B44 2048 8 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 or
4
lower
5120×2880 1
4096×2160 1
Virtual
V100L-1B 1024 16 16 16384000 3840×2160 1
Desktops
2560×1600 or
45
lower
5120×2880 1
4096×2160 1
4
Virtual
V100L-1B4 1024 16 16 16384000 3840×2160 1
Desktops
2560×1600 or
45
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
V100L-16C 16384 1 1 4096×21602 1
Workloads
Training
V100L-8C 8192 2 2 4096×21602 1
Workloads
Inference
V100L-4C 4096 4 4 4096×21602 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
V100L-16A 16384 1 1 1280×10246 16
Applications
Virtual
V100L-8A 8192 2 2 1280×10246 16
Applications
Virtual
V100L-4A 4096 4 4 1280×10246 16
Applications
Virtual
V100L-2A 2048 8 8 1280×10246 16
Applications
Virtual
V100L-1A 1024 16 16 1280×10246 16
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 or
Workstations 4
lower
7680×4320 2
Virtual
RTX8000-24Q 24576 2 2 66355200 5120×2880 or
Workstations 4
lower
Virtual
RTX8000-16Q 16384 3 3 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 or
4
lower
7680×4320 2
Virtual
RTX8000-12Q 12288 4 4 66355200 5120×2880 or
Workstations 4
lower
7680×4320 2
Virtual
RTX8000-8Q 8192 6 6 66355200 5120×2880 or
Workstations 4
lower
7680×4320 1
Virtual
RTX8000-6Q 6144 8 8 58982400 5120×2880 or
Workstations 4
lower
7680×4320 1
Virtual
RTX8000-4Q 4096 12 12 58982400 5120×2880 or
Workstations 4
lower
7680×4320 1
Virtual 5120×2880 2
RTX8000-3Q 3072 16 16 35389440
Workstations 4096×2160 or
4
lower
7680×4320 1
Virtual 5120×2880 2
RTX8000-2Q 2048 24 24 35389440
Workstations 4096×2160 or
4
lower
5120×2880 1
4096×2160 2
Virtual 9
RTX8000-1Q 1024 32 32 17694720 3840×2160 2
Workstations
2560×1600 or
4
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 or
4
lower
5120×2880 1
4096×2160 1
Virtual
RTX8000-1B 1024 32 32 16384000 3840×2160 1
Desktops
2560×1600 or
45
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
RTX8000-48C 49152 1 1 4096×21602 1
Workloads
Training
RTX8000-24C 24576 2 2 4096×21602 1
Workloads
Training
RTX8000-16C 16384 3 3 4096×21602 1
Workloads
Training
RTX8000-12C 12288 4 4 4096×21602 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
RTX8000-8C 8192 6 6 4096×21602 1
Workloads
Training
RTX8000-6C 6144 8 8 4096×21602 1
Workloads
Inference
RTX8000-4C 4096 83 12 4096×21602 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
RTX8000-48A 49152 1 1 1280×1024 1
Applications
Virtual
RTX8000-24A 24576 2 2 1280×1024 1
Applications
Virtual
RTX8000-16A 16384 3 3 1280×1024 1
Applications
Virtual
RTX8000-12A 12288 4 4 1280×1024 1
Applications
Virtual
RTX8000-8A 8192 6 6 1280×1024 1
Applications
Virtual
RTX8000-6A 6144 8 8 1280×1024 1
Applications
Virtual
RTX8000-4A 4096 12 12 1280×1024 1
Applications
Virtual
RTX8000-3A 3072 16 16 1280×1024 1
Applications
Virtual
RTX8000-2A 2048 24 24 1280×1024 1
Applications
Virtual
RTX8000-1A 1024 329 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 or
Workstations 4
lower
7680×4320 2
Virtual
RTX8000P-24Q 24576 2 2 66355200 5120×2880 or
Workstations 4
lower
7680×4320 2
Virtual
RTX8000P-16Q 16384 3 3 66355200 5120×2880 or
Workstations 4
lower
7680×4320 2
Virtual
RTX8000P-12Q 12288 4 4 66355200 5120×2880 or
Workstations 4
lower
7680×4320 2
Virtual
RTX8000P-8Q 8192 6 6 66355200 5120×2880 or
Workstations 4
lower
7680×4320 1
Virtual
RTX8000P-6Q 6144 8 8 58982400 5120×2880 or
Workstations 4
lower
7680×4320 1
Virtual
RTX8000P-4Q 4096 12 12 58982400 5120×2880 or
Workstations 4
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
RTX8000P-3Q 3072 16 16 35389440
Workstations 4096×2160 or
4
lower
7680×4320 1
Virtual 5120×2880 2
RTX8000P-2Q 2048 24 24 35389440
Workstations 4096×2160 or
4
lower
5120×2880 1
4096×2160 2
Virtual 10
RTX8000P-1Q 1024 32 32 17694720 3840×2160 2
Workstations
2560×1600 or
4
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
RTX8000P-2B 2048 24 24 17694720 3840×2160 2
Desktops
2560×1600 or
4
lower
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
5120×2880 1
4096×2160 1
Virtual
RTX8000P-1B 1024 32 32 16384000 3840×2160 1
Desktops
2560×1600 or
45
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
RTX8000P-48C 49152 1 1 4096×21602 1
Workloads
Training
RTX8000P-24C 24576 2 2 4096×21602 1
Workloads
Training
RTX8000P-16C 16384 3 3 4096×21602 1
Workloads
Training
RTX8000P-12C 12288 4 4 4096×21602 1
Workloads
Training
RTX8000P-8C 8192 6 6 4096×21602 1
Workloads
Training
RTX8000P-6C 6144 8 8 4096×21602 1
Workloads
Inference
RTX8000P-4C 4096 83 12 4096×21602 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
RTX8000P-48A 49152 1 1 1280×1024 1
Applications
Virtual
RTX8000P-24A 24576 2 2 1280×1024 1
Applications
Virtual
RTX8000P-16A 16384 3 3 1280×1024 1
Applications
Virtual
RTX8000P-12A 12288 4 4 1280×1024 1
Applications
Virtual
RTX8000P-8A 8192 6 6 1280×1024 1
Applications
Virtual
RTX8000P-6A 6144 8 8 1280×1024 1
Applications
Virtual
RTX8000P-4A 4096 12 12 1280×1024 1
Applications
Virtual
RTX8000P-3A 3072 16 16 1280×1024 1
Applications
Virtual
RTX8000P-2A 2048 24 24 1280×1024 1
Applications
Virtual
RTX8000P-1A 1024 3210 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 or
Workstations 4
lower
7680×4320 2
Virtual
RTX6000-12Q 12288 2 2 66355200 5120×2880 or
Workstations 4
lower
7680×4320 2
Virtual
RTX6000-8Q 8192 3 3 66355200 5120×2880 or
Workstations 4
lower
7680×4320 1
Virtual
RTX6000-6Q 6144 4 4 58982400 5120×2880 or
Workstations 4
lower
7680×4320 1
Virtual
RTX6000-4Q 4096 6 6 58982400 5120×2880 or
Workstations 4
lower
7680×4320 1
Virtual 5120×2880 2
RTX6000-3Q 3072 8 8 35389440
Workstations 4096×2160 or
4
lower
7680×4320 1
Virtual 5120×2880 2
RTX6000-2Q 2048 12 12 35389440
Workstations 4096×2160 or
4
lower
5120×2880 1
4096×2160 2
Virtual
RTX6000-1Q 1024 24 24 17694720 3840×2160 2
Workstations
2560×1600 or
4
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 or
4
lower
5120×2880 1
4096×2160 1
Virtual
RTX6000-1B 1024 24 24 16384000 3840×2160 1
Desktops
2560×1600 or
45
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
RTX6000-24C 24576 1 1 4096×21602 1
Workloads
Training
RTX6000-12C 12288 2 2 4096×21602 1
Workloads
Training
RTX6000-8C 8192 3 3 4096×21602 1
Workloads
Training
RTX6000-6C 6144 4 4 4096×21602 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
RTX6000-4C 4096 6 6 4096×21602 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
RTX6000-24A 24576 1 1 1280×1024 1
Applications
Virtual
RTX6000-12A 12288 2 2 1280×1024 1
Applications
Virtual
RTX6000-8A 8192 3 3 1280×1024 1
Applications
Virtual
RTX6000-6A 6144 4 4 1280×1024 1
Applications
Virtual
RTX6000-4A 4096 6 6 1280×1024 1
Applications
Virtual
RTX6000-3A 3072 8 8 1280×1024 1
Applications
Virtual
RTX6000-2A 2048 12 12 1280×1024 1
Applications
Virtual
RTX6000-1A 1024 24 24 1280×1024 1
Applications
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 or
Workstations 4
lower
7680×4320 2
Virtual
RTX6000P-12Q 12288 2 2 66355200 5120×2880 or
Workstations 4
lower
7680×4320 2
Virtual
RTX6000P-8Q 8192 3 3 66355200 5120×2880 or
Workstations 4
lower
7680×4320 1
Virtual
RTX6000P-6Q 6144 4 4 58982400 5120×2880 or
Workstations 4
lower
7680×4320 1
Virtual
RTX6000P-4Q 4096 6 6 58982400 5120×2880 or
Workstations 4
lower
7680×4320 1
Virtual 5120×2880 2
RTX6000P-3Q 3072 8 8 35389440
Workstations 4096×2160 or
4
lower
7680×4320 1
Virtual 5120×2880 2
RTX6000P-2Q 2048 12 12 35389440
Workstations 4096×2160 or
4
lower
5120×2880 1
4096×2160 2
Virtual
RTX6000P-1Q 1024 24 24 17694720 3840×2160 2
Workstations
2560×1600 or
4
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 or
4
lower
5120×2880 1
4096×2160 1
Virtual
RTX6000P-1B 1024 24 24 16384000 3840×2160 1
Desktops
2560×1600 or
45
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
RTX6000P-24C 24576 1 1 4096×21602 1
Workloads
Training
RTX6000P-12C 12288 2 2 4096×21602 1
Workloads
Training
RTX6000P-8C 8192 3 3 4096×21602 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
RTX6000P-6C 6144 4 4 4096×21602 1
Workloads
Inference
RTX6000P-4C 4096 6 6 4096×21602 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
RTX6000P-24A 24576 1 1 1280×1024 1
Applications
Virtual
RTX6000P-12A 12288 2 2 1280×1024 1
Applications
Virtual
RTX6000P-8A 8192 3 3 1280×1024 1
Applications
Virtual
RTX6000P-6A 6144 4 4 1280×1024 1
Applications
Virtual
RTX6000P-4A 4096 6 6 1280×1024 1
Applications
Virtual
RTX6000P-3A 3072 8 8 1280×1024 1
Applications
Virtual
RTX6000P-2A 2048 12 12 1280×1024 1
Applications
Virtual
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.
These platforms are typically configured to operate in Non-Uniform Memory Access (NUMA)
mode; physical memory is arranged sequentially in the address space, with all the memory
attached to each socket appearing in a single contiguous block of addresses. The cost of
accessing a range of memory from a CPU or GPU varies; memory attached to the same
socket as the CPU or GPU is accessible at lower latency than memory on another CPU socket,
because accesses to remote memory must additionally traverse the interconnect between
CPU sockets.
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.
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.
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:
By default on Windows Server operating systems, the NVIDIA Notification Icon application is
started with every Citrix Published Application user session. This application might prevent the
Citrix Published Application user session from being logged off even after the user has quit all
other applications.
The NVIDIA Notification Icon application appears in Citrix Connection Center on the endpoint
client that is running Citrix Receiver or Citrix Workspace.
The following image shows the NVIDIA Notification Icon in Citrix Connection Center for a
user session in which the Adobe Acrobat Reader DC and Google Chrome applications are
published.
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.
Icon application is disabled on any virtual delivery agent (VDA) that is created from a master
image, set this key in the master image.
Perform this task from the VM on which the Citrix Published Application sessions will be
created.
Before you begin, ensure that the NVIDIA vGPU software graphics driver is installed in the VM.
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>
‣ Using XenCenter
‣ 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:
[root@xenserver ~]# xe vm-param-set uuid=vm-uuid VCPUs-params:mask=16,17,18,19
3. Use xl vcpu-list to list the current assignment of vCPUs to physical CPUs:
[root@xenserver ~]# xl vcpu-list
Name ID VCPU CPU State Time(s) CPU Affinity
Domain-0 0 0 25 -b- 9188.4 any cpu
Domain-0 0 1 19 r-- 8908.4 any cpu
Domain-0 0 2 30 -b- 6815.1 any cpu
Domain-0 0 3 17 -b- 4881.4 any cpu
Domain-0 0 4 22 -b- 4956.9 any cpu
Domain-0 0 5 20 -b- 4319.2 any cpu
Domain-0 0 6 28 -b- 5720.0 any cpu
Domain-0 0 7 26 -b- 5736.0 any cpu
test-image-win7-32 34 0 9 -b- 17.0 4-15
test-image-win7-32 34 1 4 -b- 13.7 4-15
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.
‣ 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-2021 NVIDIA Corporation. All rights reserved.