Known limitations you may encounter with NVIDIA RTX PRO 6000 Blackwell Server Edition GPU Linodes

There are a few known limitations present across the current 1-, 2-, and 4-card Limited Availability plans, as well as the new 8-card Beta configurations for NVIDIA RTX™ PRO 6000 Blackwell Server Edition GPU Linodes. These issues are detailed below, along with workarounds and information to help you plan your deployment.

Watchdog may not automatically reboot Blackwell GPU instances

While we continue to optimize the management framework for high-capacity compute plans, the Watchdog service (Lassie) may not automatically reboot RTX PRO 6000 Blackwell instances following a manual shutdown. This behavior is primarily observed on multi-GPU plans. If an instance remains powered off after a shutdown, it can be restarted manually through the Cloud Manager or the Linode API.

Linode deletions may be slow or hang for GPU plans

Due to the large memory allocation and hardware cleanup required for RTX PRO 6000 Blackwell plans, the deletion process may occasionally take several minutes to complete. During this time, the instance may remain visible in the Cloud Manager or API beyond the standard timeout window. If a deletion does not complete within five minutes, please contact Support for assistance.

Migration support for GPU-accelerated instances

Instances utilizing hardware passthrough currently support cold and warm migration workflows. Because these configurations require a direct hardware assignment to the guest, live migrations are not supported at this time.

If you need to move your instance to a different host or region, you must initiate a migration that allows for a controlled restart of the virtual machine.

vNUMA topology change during resize

Resizing from a 4-GPU plan (single NUMA node) to an 8-GPU plan (dual NUMA node) changes the guest ACPI topology. A reboot is required for vNUMA and PCIe layout to take effect.

Cross-socket peer-to-peer (P2P) performance

The 8-GPU platform splits resources across two physical CPU sockets and PCIe expander bridges (0000:20 and 0000:40). Because of this hardware-level architecture, direct peer-to-peer (P2P) memory copies between GPUs on different root complexes may experience reduced bandwidth compared to communication between GPUs sharing the same bridge. While exposing the hardware topology via vNUMA lets your software see these groupings to optimize scheduling, it does not bypass this physical layout constraint.

Operating system compatibility for vNUMA

To automatically discover and use the exposed vNUMA topology, your compute instance needs to run a standard, supported Linux distribution. If you are deploying minimal disk images, custom kernels, or unsupported operating systems, the guest OS may fail to detect the underlying hardware groupings. For optimal performance, we recommend using our standard distribution images.

Installing NUMA management tools

Depending on your image configuration, NUMA-aware command-line tools and libraries (such as numactl, numastat, and libnuma) may not be pre-installed by default—especially on minimal or custom cloud images. If your orchestration or workload requires these tools, you can easily install them manually using your distribution's package manager:

• Ubuntu/Debian: sudo apt install numactl
• RHEL/Rocky Linux: sudo dnf install numactl

Request assistance

If you encounter any issues, open a support ticket.