NVIDIA RTX PRO 6000 Blackwell Max-Q in VMs: passthrough, MIG and why there is no vGPU

What NVIDIA supports for the Max-Q in virtual machines

The NVIDIA RTX PRO 6000 Blackwell Max-Q Workstation Edition can run in a virtual machine only as a whole card passed through to one guest. NVIDIA does not list it for vGPU, so it has no time-sliced or MIG-backed vGPU profiles; NVIDIA's MIG guide does let a Linux guest split a passed-through card into MIG instances for its own containers. For several VMs per card, vGPU on vSphere or NVIDIA AI Enterprise support, the RTX PRO 6000 Blackwell Server Edition is the edition NVIDIA lists.

NVIDIA list of GPUs supported by vGPU software (updated 2 October 2026), NVIDIA vGPU product support matrices for vSphere, RHEL with KVM and Ubuntu (29 September 2026), NVIDIA MIG user guide (13 October 2026), NVIDIA AI Enterprise 8.2 support matrix, NVIDIA RTX PRO 6000 family page; all read 24 October 2026.

Server makers draw the same line. Lenovo's product guide LP2364 for the Max-Q, updated on 8 May 2026, gives "vGPU software support" as "No support" and records that Lenovo "removed the NVIDIA vGPU Software part numbers since the GPU does not support vGPUs". It lists the card as an option for two servers only, the ThinkSystem SR655 V3 and SR665 V3. The three editions side by side are in our comparison of the RTX PRO 6000 Server, Workstation and Max-Q editions.

Whole-card passthrough on KVM and Proxmox

With passthrough, the hypervisor hands the whole PCIe device to one VM, on KVM through the VFIO driver, and the guest loads the normal NVIDIA driver as if it ran on bare metal. The guest sees all 96 GB, the full compute and, if they are switched on, the four DisplayPort outputs. Nothing is shared: one card, one VM, and a host with four Max-Q cards runs at most four GPU VMs, or fewer if one VM takes two or four cards for a model split across them.

NVIDIA's own documents say little about this case. We found no NVIDIA page that lists a hypervisor as supported for passthrough of this edition. The MIG user guide's "Supported Configurations" page lists "GPU pass-through virtualization to Linux guests on top of supported hypervisors" for MIG-capable GPUs, and its GPU table names the "RTX PRO 6000 Blackwell Max-Q Workstation Edition" with four instances. In practice, Max-Q passthrough relies on the hypervisor's own PCIe passthrough, without a support matrix from NVIDIA.

Three practical points follow from the sources further down.

• One VM per card, sized for its model. A VM that serves a 70B model in FP8 on one card needs the whole 96 GB anyway. By our users-per-card rule a card leaves 83.0 GiB for weights and cache (0.9 × 95.6 GiB − 3 GiB), which holds 12 conversations of 8,192 tokens with Llama 3.3 70B in FP8.
• Several cards in one VM. A VM with two or four cards for tensor parallelism loses part of the peer-to-peer path. NVIDIA's NCCL troubleshooting guide states that "Virtual machines require ACS to function, hence disabling ACS is not an option", and ACS can send GPU-to-GPU traffic through the processor. Our guide to P2P, IOMMU and ACS on Linux shows how to measure what is left.
• No live migration. A passed-through card is tied to its host, so maintenance on the host means shutting the VM down. On vSphere, Broadcom's knowledge base article 428701 allows snapshots of passthrough VMs only when they are powered off.

Which edition and how many cards fit your virtual machines depends on the hypervisor and the number of VMs per card; send us your hypervisor and the VMs you plan, and our team replies with the edition and a configuration.

Reset problems with several cards in Proxmox and KVM

The most detailed public report is a Proxmox support forum thread titled "Passthrough RTX 6000/5090 CPU Soft BUG lockup, D3cold to D0, after guest shutdown". It started on 13 July 2025 and ran to 57 posts, the last of them in December 2025. The hosts in it carried two to eight cards, and one user ran three nodes with eight cards each.

The reported symptoms are consistent. After a guest shuts down, the host's kernel reports soft lockups as it tries to bring the card back from the D3cold power state, logs lines such as "vfio-pci ... not ready 32767ms after FLR; waiting", and in some cases freezes. One user with eight cards per host saw cards disappear from the host after a few VM power cycles, with a different card failing each time. Users with the Max-Q described it as the edition most affected: one reported that a udev rule fixed 600 W cards but not the Max-Q, and later replaced his Max-Q cards with 600 W cards. Another saw Max-Q crashes on two older dual-Xeon workstations and a Threadripper board, but not on an older Intel desktop board.

The Server Edition is not free of passthrough issues either. In the same thread, a user with eight 600 W Server Edition cards per node reported guests whose BARs were never mapped, and posted the VM settings he then recommended, among them a larger 64-bit PCI hole. NVIDIA had passed the report "to developers", according to a user, and neither NVIDIA nor Proxmox staff posted a fix in the thread. These are reports from individual systems, not a measurement, and they date from Proxmox kernels 6.14 to 6.18 in late 2025.

Reported workarounds and what they change

Users in the thread reported these changes, each working for some systems and not for others.

Proxmox support forum thread "Passthrough RTX 6000/5090 CPU Soft BUG lockup, D3cold to D0, after guest shutdown", posts of July to December 2025, read 24 October 2026. Results as reported by users of single systems.

Each change has a cost. Keeping the card out of D3cold and idle D3 means it no longer enters those power-saving states while no VM uses it, so an idle host draws more, by our reading of what the settings do. A newer kernel than the one your Proxmox or RHEL release ships moves the host outside the vendor's tested configuration. Turning off kernel modesetting in the guest suits compute VMs and gives up the guest's own graphical console on that card. Firmware updates come from NVIDIA or the server maker; apply them to all cards of a host at the same level.

On a new Max-Q host, test the cycle that triggers the failure before going live: start and shut down every VM, with the cards in use, many times in a row, and watch the host log for FLR and D3cold messages. A host that survives that cycle at acceptance still needs the same check after each kernel or driver update. Our guide to burn-in and acceptance testing describes the rest of the acceptance run.

MIG on the host or inside the guest

The Max-Q supports MIG with up to four instances: NVIDIA's datasheet gives 4 × 24 GB, 2 × 48 GB or 1 × 96 GB. As our MIG setup guide for RTX PRO Blackwell explains, MIG on the RTX PRO 6000 needs Linux, driver 575.51.03 or later, current card firmware and the card switched to compute mode with NVIDIA's DisplayModeSelector, which turns the display outputs off.

There are two places to use it.

1. On a bare-metal Linux host. The host splits each card into instances and gives them to containers or Kubernetes pods, which the MIG guide lists as "Bare-metal, including containers and MIG with Kubernetes". This is the way to give four teams a 24 GB slice each without virtual machines. Our article on GPU sharing in Kubernetes covers the scheduling.
2. Inside one passthrough VM. NVIDIA's MIG guide states that under Linux guests on supported hypervisors, with the GPU in passthrough, the same workflows, tools and profiles as on bare metal can be used. The VM owns the whole card and splits it for its own workloads.

What MIG cannot do on the Max-Q is put its instances into different virtual machines. The MIG guide's virtualisation page names MIG-backed vGPU as the way to run several VMs in parallel on one MIG GPU, and the Max-Q has no vGPU support. A VM per 24 GB slice, as on the Server Edition, needs vGPU. The four instances and their engines are listed in our guide to RTX PRO 6000 MIG profiles.

When you need the RTX PRO 6000 Server Edition

The Max-Q is a workstation card. NVIDIA rates it for "up to four GPUs in a single system" and describes the family's Server Edition as "designed for multi-GPU server deployments requiring passive cooling". For virtual machines, five requirements point to the Server Edition.

• Several VMs per card. NVIDIA lists time-sliced and MIG-backed vGPU types for the Server Edition, up to four MIG slices of 24 GB and 12 compute VMs of 8 GB per card, as our guide to RTX PRO 6000 Server Edition vGPU profiles shows.
• VMware vSphere with vGPU. NVIDIA's vSphere matrix lists the Server Edition for VCF 9.1, VCF 9.0.1 or later and ESXi 8.0 Update 3g or later; the Max-Q is not in it.
• NVIDIA AI Enterprise support. The 8.2 support matrix lists the RTX PRO 6000 Blackwell Server Edition and the RTX PRO 4500 Blackwell Server Edition among its discrete Blackwell GPUs, in servers on NVIDIA's certified-systems list, and does not list the Max-Q.
• A long support window. The Server Edition is on vGPU 19, the long-term branch NVIDIA supports until July 2028.
• A rack server in continuous operation. For continuous operation in a rack we recommend the Server Edition. Many server makers do not list the Max-Q for their GPU servers: in a dense chassis each blower's intake sits against the next card, and the airflow is designed for passive cards; our checklist for the Max-Q in a rack server goes through the cases where a maker does list it.

The Max-Q stays a good fit where one workstation or one VM owns each card: a deskside machine with two to four cards for a team, a lab host where each researcher's VM gets a whole card, or a bare-metal Linux box that shares cards by MIG among containers. Our pages on two Max-Q cards in a workstation and four in one workstation size those builds.

We supply the RTX PRO 6000 in all three editions, as cards or in workstations and servers built to order, and the Server Edition with vGPU or NVIDIA AI Enterprise licences on the same quote. Tell us how many VMs share each card, and we say which edition fits before you order.

Licences for passthrough, MIG and vGPU

Licensing follows the edition. The Max-Q has no vGPU profiles, so vGPU licences do not apply to its virtual machines. On the Server Edition, NVIDIA's client licensing guide maps Q-series vGPUs to RTX vWS, B-series to vPC or vWS and A-series to vApps, and states that "In GPU pass-through mode on Linux, a physical GPU requires a vWS license". Compute vGPUs need NVIDIA AI Enterprise, which NVIDIA licenses "on a per-GPU basis". Our page on NVIDIA AI Enterprise and vGPU licences lists the editions we supply.

FAQ