VMware AI ReadyNode Certification: Why Server and GPU Compatibility Is Not Enough

VMware AI ReadyNode certification is a configuration decision. Match the server, GPU, operating mode, and software evidence before approving an enterprise AI platform.

TL;DR

Broadcom’s November 12, 2026 guidance clarifies an important boundary in enterprise AI infrastructure design: a vSphere-certified server, a separately listed GPU, and a compatible accelerator driver do not automatically create a VMware AI ReadyNode-certified configuration. AI ReadyNode qualification is an integrated certification process that covers the server, accelerator, supported virtualization modes, and functional testing.

The exact records produce different outcomes for the two Dell examples. PowerEdge R760 with L40 has Broadcom VM DirectPath certification evidence, but L40 is not listed in the current R760 AI ReadyNode entries. Those entries identify L40S and H100 instead. PowerEdge XE9680 with HGX H200 is explicitly AI ReadyNode-listed in record 58009 and record 60033, including NVIDIA vGPU support. The deployment must still match the CPU series, release, allocation mode, and software requirements.

The takeaway: Treat AI ReadyNode certification as a specific, verifiable configuration requirement rather than a compatibility claim assembled from multiple vendor catalogs. Validate the complete hardware and software combination before procurement approval, then separately prove that the deployed platform meets its workload and operational requirements.

Continue with VMware by Broadcom: Architecture and Operations and the Enterprise AI Strategy and Architecture hub.

Introduction

Consider a familiar infrastructure design review.

An enterprise is preparing to deploy GPU-accelerated inference and model fine-tuning workloads on VMware Cloud Foundation. The infrastructure team has selected a Dell server, identified a suitable NVIDIA GPU, and confirmed that the individual components appear in vendor compatibility documentation.

The server has a certification record. The GPU is supported by its manufacturer. A compatible driver family is available. On paper, the infrastructure looks ready.

Procurement wants to release the purchase order, the architecture team wants to approve the bill of materials, and the AI team wants to begin deployment planning.

One question remains unresolved:

Is this exact server-and-GPU configuration certified as a VMware AI ReadyNode for the intended deployment?

That question matters because individual compatibility records establish different things. A server may be certified to run ESX without being qualified for every GPU configuration. A GPU may operate through PCI passthrough without being certified as part of an AI ReadyNode. An accelerator host-driver listing may establish software compatibility without proving that a particular OEM server has completed the integrated certification process.

On November 12, 2026, Broadcom published Unlocking AI Performance: Benefits and Certification of VMware AI ReadyNodes, explaining the certification process and directing customers to the AI ReadyNode category in the Broadcom Compatibility Guide.

The publication is not an announcement that every NVIDIA-equipped server is now qualified for AI workloads on VCF. It explains how a distinct certification designation is earned and where that designation must be verified.

For architects and platform leaders, the practical implication is significant. Hardware selection is incomplete when the evidence only covers individual components. The evidence must match the deployment being proposed.

This article examines the certification boundaries, applies them to two Dell PowerEdge configurations, and defines a practical evidence-based approval process for enterprise AI infrastructure.

Scope and evidence: This analysis uses live Broadcom certification records and Dell and NVIDIA documentation checked on November 13, 2026. The findings below identify documented configurations and their certification boundaries. They do not certify a customer deployment. Exact VCF and ESX builds, CPU series, GPU allocation modes, firmware, drivers, and guest operating systems still need deployment-specific validation. No workload or production acceptance tests were performed for this article.

What Broadcom Actually Certifies with AI ReadyNodes

The VMware AI ReadyNode program is intended to reduce uncertainty when deploying supported GPU-accelerated AI workloads on VMware infrastructure.

Broadcom describes AI ReadyNodes as server systems that have undergone integrated qualification for supported GPU configurations. The qualification process builds on existing hardware certification programs but adds the testing required for AI ReadyNode designation.

The distinction is important because each certification program answers a different technical question.

The Four Stages of AI ReadyNode Certification

Broadcom states that OEM and ODM partners complete the server certification, general GPU passthrough certification, and GPU functional tests. Broadcom works with GPU vendors on the DirectPath GPUs and Accelerators certification.

These are activities performed as part of the vendor certification program. They should not be confused with four separate certification exercises that an enterprise customer must reproduce.

More importantly, completing only a subset does not qualify a system for the AI ReadyNode designation.

Why General GPU Passthrough Certification Is Not Enough

The Broadcom Compatibility Guide includes a category called VM DirectPath I/O for General GPU.

This category identifies specific server, GPU, and ESX combinations tested for direct passthrough. Its records also provide associated guest operating system and workload information.

That is valuable compatibility evidence.

However, GPU passthrough by itself does not establish the broader AI ReadyNode qualification. A passthrough-certified configuration may support the workloads and guest operating systems named in its applicable records without possessing the AI ReadyNode designation.

The distinction matters when a purchase specification explicitly requires a certified AI ReadyNode.

If the procurement requirement is simply a supported GPU passthrough configuration for a specific workload, the applicable DirectPath and vendor support records may provide a different route to approval. That should be a deliberate support decision, not an automatic substitution for an AI ReadyNode requirement.

Why an Accelerator Driver Listing Is Not Server Certification

The DirectPath GPUs and Accelerators category serves another purpose.

Broadcom uses this certification area with accelerator vendors to qualify applicable host-driver integration. These drivers can enable operational capabilities such as GPU assignment, supported sharing, and additional management visibility.

A compatible accelerator-driver entry does not independently establish that the GPU is qualified inside a specific Dell, HPE, Lenovo, or other OEM server.

The server context must come from the applicable server-and-GPU certification records.

This is particularly important for vGPU designs, where the hypervisor-side software, GPU model, guest driver, and selected vGPU profile introduce additional compatibility dependencies.

The AI ReadyNode Evidence Boundary

The architecture mistake is treating compatibility as additive.

A design review may gather several individually valid records and assume that the combined solution inherits all their certifications. But certification evidence is scoped to the configuration and testing performed.

An AI ReadyNode designation must be established through the applicable integrated qualification record.

The following decision flow shows how the evidence should be evaluated.

The important distinction is between the two approval boundaries.

Certification and support approval establishes that the proposed configuration matches the required vendor evidence. Production service acceptance establishes that the implemented environment meets the organization’s operational and workload requirements.

Neither automatically replaces the other.

This also means an unverified system should not immediately be labeled unsupported. An unavailable, inaccessible, or undiscovered record is an evidence gap. A confirmed vendor exclusion is a different finding and should be treated accordingly.

Applying the Guidance to Dell PowerEdge R760 and XE9680

Both server-and-GPU pairings appear in Dell and NVIDIA hardware documentation. Their Broadcom certification findings are different. The current configuration records, including the individual certification features, establish the distinction.

Dell PowerEdge R760 with NVIDIA L40

Dell’s R760 expansion-card installation guidelines explicitly list L40, with up to two cards in the specified riser configurations. Other riser configurations permit fewer cards, so two cards are not supported in every chassis build. NVIDIA’s certified-system catalog separately lists R760 with two L40 GPUs and two L40S GPUs.

Broadcom VM DirectPath evidence is confirmed for R760 with L40. Record 7362b4e9-4d05-355d-8102-5c83a5894b6d covers the Intel Xeon Gold 6400/5400 Sapphire Rapids CPU series. Its ESXi 9.1 certification 9183745 identifies NVIDIA L40, a Compute workload, Windows 10 (64 bit), and Dell BIOS 1.4.4 in UEFI mode. This is a specific certification example; it does not establish support for an arbitrary Linux guest, vGPU profile, or different CPU configuration.

The AI ReadyNode result is different. The current R760 AI ReadyNode records 55720 (Gold 6400/5400), 58972 (Platinum 8500), and 59031 (Gold 6500/5500) identify L40S and H100 80GB. They do not list L40. For example, record 55720’s ESXi 9.1 certificate 9174806 identifies L40S, a maximum of two GPUs, and NVIDIA vGPU support.

The R760/L40 pairing therefore has hardware and DirectPath certification evidence, but it should not be described as AI ReadyNode-certified from the current R760 entries. If that designation is mandatory, resolve the exact requirement with the vendors or select a separately documented certified configuration. L40 and L40S are distinct products; substituting one record for the other changes the evidence.

Dell PowerEdge XE9680 with NVIDIA HGX H200

Dell’s GPU specifications identify eight HGX H200 141 GB, 700 W SXM5 GPUs connected through NVLink. NVIDIA’s certified-system catalog lists XE9680 with HGX H200 8-GPU. This is the HGX/SXM platform, not H200 NVL.

Broadcom AI ReadyNode certification is confirmed for HGX H200 on XE9680. Record 58009 covers Intel Xeon Platinum 8400 Sapphire Rapids; record 60033 covers Intel Xeon Platinum 8500 Emerald Rapids. The release-specific certificates below explicitly identify HGX H200 8-GPU 141GB, a maximum of eight GPUs, and NVIDIA vGPU support.

These H200 certificates list Dell BIOS 2.7.4 in UEFI mode. That is the recorded test baseline, not an instruction to downgrade firmware. Apply the vendor’s current BIOS guidance and retain the certification and change evidence appropriate to the deployed configuration. A release listing also does not establish every VCF bill of materials, guest OS, driver, vGPU profile, or patch build.

There is still an OEM documentation discrepancy to reconcile. Dell’s installation-manual OS-GPU table names H100 under ESXi and omits H200. However, Dell also publishes an XE9680 submission with eight H200 SXM GPUs on ESXi 9.0.0. The benchmark is evidence of a tested virtualized configuration, not a replacement for OEM support terms. The manual omission does not invalidate Broadcom’s explicit H200 certification or justify describing the system as unlisted. Retain the matching Broadcom evidence and reconcile Dell’s applicable support documentation before finalizing the deployment baseline.

Side-by-Side Design Assessment

These findings distinguish certification from deployment approval. They do not declare every R760/L40 use unsupported, and they do not declare every XE9680/H200 deployment production-ready.

Turn AI ReadyNode Certification into a Versioned Design Contract

A server model and GPU name are not enough to describe a deployable AI configuration.

For enterprise architecture purposes, the approved configuration should be treated as a versioned contract between the physical infrastructure, virtualization platform, accelerator software, and guest workload.

The contract should identify not only what is intended to run, but also the vendor evidence that permits that combination.

The Configuration Details That Must Match

Not every field will necessarily appear in one AI ReadyNode result. The architecture record should reconcile the relevant Broadcom, Dell, and NVIDIA documents rather than expecting one page to describe the entire software stack.

This becomes particularly important during upgrades. An originally approved configuration can change when a host image, NVIDIA driver, firmware package, guest OS, or GPU allocation method changes.

The certification and support evidence must be reviewed against that new target state. The exact-build compatibility and transition plan applies the same discipline to a broader VMware platform change.

GPU Operating Mode Is a Certification Boundary

VMware GPU deployment generally begins with two important operating models.

DirectPath passthrough assigns a physical GPU directly to a virtual machine. The guest uses the assigned device, subject to the applicable hardware, hypervisor, device-driver, and workload support requirements.

NVIDIA vGPU uses supported NVIDIA host software and a virtual GPU configuration to expose GPU resources to virtual machines. The available sharing, profiles, and migration behavior depend on the supported GPU and software combination.

These modes should not be treated as equivalent simply because both provide accelerator access to a virtual machine.

For example, a Broadcom record identifying a specific GPU in passthrough mode does not automatically establish support for sharing that GPU among multiple VMs through vGPU.

Likewise, a GPU’s presence in the physical host inventory does not demonstrate that the selected vGPU profile is available, supported, licensed, or usable by the intended guest.

If Multi-Instance GPU (MIG) is part of the design, that introduces another configuration dependency. MIG support and the relevant profile combinations must be established for the actual GPU, software release, hypervisor, and deployment mode. It should not be inferred from a general accelerator-family capability.

The architecture approval should explicitly identify which allocation mechanism is being purchased and which vendor records permit it. For HGX designs using NVSwitch, NVIDIA’s AI Enterprise 8.3 NVSwitch guidance restricts VMware vSphere GPU passthrough to full-node configurations and limits NVSwitch-enabled vGPU support to specified profiles. A vGPU certification flag does not grant arbitrary fractional, MIG-backed, or one-GPU passthrough configurations.

NVIDIA Driver Compatibility Is Not a Simple Version-Matching Exercise

NVIDIA’s vGPU documentation adds an important software qualification.

For vGPU deployments, the NVIDIA vGPU Manager on the hypervisor host and the NVIDIA guest driver must form a documented compatible combination.

Those components do not necessarily need identical version numbers or even identical release branches.

NVIDIA documents allowed same-release combinations and specific cross-branch compatibility relationships. The permitted combinations depend on the selected manager and guest-driver releases.

The NVIDIA Virtual GPU Software 21.0 release notes provide a useful example. They document compatible combinations involving the 21.0 manager and supported guest-driver releases from designated earlier branches.

They also explain that when different release branches are paired, the supported functionality is limited to the intersection of the relevant software, hardware, and operating-system support.

An incompatible pairing can prevent a vGPU from initializing successfully.

The operational lesson is straightforward: newer is not automatically compatible.

The appropriate process is to select the required NVIDIA software release, identify the applicable ESX and GPU support, and then record the host-manager and guest-driver combination explicitly permitted by NVIDIA.

Release 21.0 is an illustration of that dependency, not a recommended software baseline for either Dell configuration discussed here.

Also, this manager-to-guest compatibility rule is specific to NVIDIA vGPU deployments. A direct-passthrough design has a different host-side software path and should be validated against its own documented requirements.

Make Certification a Procurement Approval Gate

Compatibility review is often treated as a technical activity that happens after a hardware quote has been accepted.

For enterprise AI infrastructure, that sequence can create avoidable procurement risk.

Once GPU systems have been ordered, the organization may face substantial lead times, configuration constraints, installation commitments, licensing dependencies, and change costs. A support gap discovered after delivery can turn what appeared to be a straightforward deployment into a redesign.

The better approach is to make exact configuration evidence an input to procurement approval.

Separate the Approval Decisions

Certification and support evidence should be resolved before procurement approval. Workload acceptance follows deployment and addresses a separate decision.

If a procurement specification promises a VMware AI ReadyNode, the matching AI ReadyNode evidence should be attached to the approved bill of materials. A collection of independent certification records is not a substitute for that requirement.

If the business does not require the AI ReadyNode designation, the team may evaluate another explicitly supported GPU configuration. That is a different architecture decision and should be documented as such.

It should not be described as AI ReadyNode-certified unless the applicable designation has actually been verified.

A Practical Configuration Evidence Record

An architecture team does not need an elaborate tool to begin preserving this evidence. A structured record linked to the bill of materials and architecture decision is enough.

The following YAML is an illustrative governance record, not a Broadcom or Dell configuration schema. It preserves the confirmed R760/L40 DirectPath evidence and the separate unresolved AI ReadyNode requirement. It is not an executable deployment manifest.

apiVersion: dtd.example/v1
kind: GPUCertificationEvidence

design:
  server: Dell PowerEdge R760
  gpu: NVIDIA L40
  gpuQuantity: not_selected
  targetVCFVersion: not_selected
  targetESXBuild: not_selected
  allocationMode: not_selected

certification:
  requiredDesignation: VMware AI ReadyNode
  broadcomAIReadyNodeStatus: l40_not_listed_in_current_r760_entries
  broadcomAIReadyNodeRecordsChecked: [55720, 58972, 59031]
  broadcomDirectPathRecordId: "7362b4e9-4d05-355d-8102-5c83a5894b6d"
  broadcomDirectPathCertificateId: 9183745
  evidenceScope: "Gold 6400/5400; ESXi 9.1; Windows 10; Compute"
  broadcomRecordURL: "https://compatibilityguide.broadcom.com/details?program=vmdirect&productId=7362b4e9-4d05-355d-8102-5c83a5894b6d"
  evidenceCheckedOn: 2026-11-13
  nvidiaCertifiedSystemEvidence: identified
  dellConfigurationEvidence: identified_riser_configuration_must_match

software:
  hostDriver: not_selected
  guestDriver: not_selected
  guestOS: not_selected
  firmwareBaseline: not_selected

ownership:
  platformArchitect: not_assigned
  hardwareSupportOwner: not_assigned
  gpuPlatformOwner: not_assigned
  operationsOwner: not_assigned

acceptance:
  workloadProfile: not_defined
  passCriteria: not_defined
  testEvidence: not_run

decision:
  status: needs_validation
  procurementApproval: hold
  productionAcceptance: not_started

Successful use of a record like this does not mean replacing pending values with optimistic assumptions. It means resolving them against specific vendor documentation and retaining the record identifiers and applicable restrictions.

For XE9680/H200, the record should identify the applicable Broadcom product and release-specific H200 certificate, retain the confirmed vGPU designation, and track the remaining deployment parameters and Dell documentation reconciliation. Its AI ReadyNode field should record the verified listing.

The approved record should become part of the configuration baseline that the deployment and operations teams inherit.

Define Ownership Before a Support Question Appears

The procurement control also needs clear responsibility.

The hardware vendor or OEM should provide the applicable hardware and certification evidence. The platform architect should reconcile that evidence with the target virtualization architecture. The GPU or AI platform owner should confirm the intended GPU allocation model and software requirements.

Procurement should verify that the approved purchase configuration matches the signed-off technical design. Operations should inherit the final compatibility baseline and understand which changes trigger revalidation.

This responsibility split becomes valuable when a vendor support case crosses multiple products. The organization can identify the exact approved combination rather than asking each vendor to interpret a partially documented configuration after a failure.

Certification Must Remain Separate from Production AI Acceptance

A certified hardware configuration reduces one class of infrastructure risk. It does not prove that an organization’s actual AI service will meet its performance, availability, security, or recovery objectives.

A production AI deployment introduces additional dependencies that hardware certification alone cannot resolve.

An inference service may depend on GPU memory availability, model loading, network connectivity, shared storage, authentication, container images, runtime libraries, scheduling, monitoring, and application-specific latency objectives.

A fine-tuning workload may place different demands on accelerator memory, GPU interconnects, storage throughput, checkpointing, and job recovery.

Those requirements need explicit acceptance criteria.

What the Delivery Team Should Actually Test

A useful production acceptance plan should distinguish several test categories.

The acceptance plan should specify actual models, workload profiles, data sets, test conditions, and pass criteria. Without those inputs, a generic GPU benchmark cannot establish that a business service meets its objectives.

Availability and mobility capabilities also require particular attention. GPU-backed virtual machines do not necessarily inherit every maintenance, migration, or recovery behavior available to conventional CPU-only virtual machines. Those capabilities must be established for the selected device and allocation mode.

The principle is to prove the required service behavior rather than assume it from the certification designation. For the service-level questions beyond hardware health, Your GPU Is Up. Is Your AI? introduces a proposed inference resilience profile and benchmark design; it has not been empirically validated.

Day-2 Operations: Certification Evidence Has a Lifecycle

The certification decision should not disappear after installation.

Over the lifetime of an enterprise AI platform, several routine changes can alter the compatibility state: an ESX patch, a platform firmware update, a new NVIDIA driver branch, a guest kernel update, a change in GPU allocation mode, or the replacement of a failed device.

The resulting configuration may still be supported. But supportability must be checked against the updated configuration rather than assumed from the original deployment record.

A practical operating model should retain the last approved configuration, record the proposed changes, compare the target state against applicable compatibility sources, and define rollback or recovery actions before execution.

This does not require every change to restart the entire AI ReadyNode certification process. The vendor certification remains a vendor activity.

The customer’s responsibility is to determine whether the changed deployment remains within the documented support boundaries and whether the affected workloads still meet their acceptance criteria.

This distinction prevents two common operational failures.

The first is treating a previously approved configuration as permanently approved, regardless of later software or hardware changes.

The second is treating successful GPU initialization after an upgrade as complete validation of the AI platform.

A GPU can be visible and usable while an application experiences lower throughput, higher latency, scheduling failures, or changed recovery behavior. Operational evidence must extend beyond device detection.

Common Failure Patterns in AI Hardware Qualification

Several mistakes are worth preventing before the next procurement or architecture review.

• Substituting similar server models. PowerEdge R760 and R760xa have separate hardware identities and should be checked against their own records.
• Substituting similar GPU products. L40 and L40S, or HGX H200 and H200 NVL, must be evaluated as distinct configurations.
• Treating a driver listing as server qualification. Accelerator host-driver certification is not proof that the device is certified within a specific OEM server.
• Ignoring the software baseline. An exact GPU and server match is insufficient if the intended ESX, guest OS, mode, or NVIDIA software combination is outside the applicable support scope.
• Interpreting incomplete search results as negative certification. An inaccessible or undiscovered compatibility record requires further verification, not an unsupported claim that the configuration failed certification.
• Equating certification with workload performance. Hardware qualification does not replace representative inference, fine-tuning, maintenance, and recovery testing.

These problems have a common cause: an architecture decision is made at a broader level of abstraction than the evidence actually supports.

The correction is not more paperwork. It is better alignment between the proposed bill of materials, the certification scope, and the deployed configuration.

Conclusion

Broadcom’s November 12, 2026 publication reinforces an important requirement for VMware-based enterprise AI infrastructure: AI ReadyNode certification must be established through the applicable integrated qualification process, not inferred from independent server, GPU, or driver listings.

That distinction changes how architects should evaluate hardware proposals. The question is no longer limited to whether a server can run ESX or whether a GPU appears in a compatible-hardware catalog. The decision must consider the exact server-and-GPU combination, operating mode, software baseline, vendor support records, and the certification designation required by the organization.

The Dell examples now demonstrate two distinct outcomes. R760 with L40 has confirmed DirectPath evidence but is not listed with L40 in the current R760 AI ReadyNode entries. XE9680 with HGX H200 has explicit AI ReadyNode and NVIDIA vGPU evidence for the CPU series and ESXi releases documented above.

Customer deployment approval remains separate. The R760 design must satisfy the actual certification requirement and exact DirectPath support scope. The XE9680 design must match its certified configuration, reconcile the OEM documentation, and complete software and workload acceptance checks. Neither a product listing nor successful device initialization proves the service outcome.

The most useful procurement rule is simple: approve the exact supported configuration, retain the evidence, and then test the service that depends on it.

A certified component is an input to a design. A supported configuration is the basis for deployment. A validated service is the operational outcome.

Related Reading

• Private AI Is Not Model Hosting: Place GPU qualification within the wider VCF operating model.
• vSphere 8 to VMware 9.x: Building the Exact Build Compatibility and Transition Plan: Retain a supported software and hardware baseline through change.
• Your GPU Is Up. Is Your AI?: Explore the proposed service continuity framework and its stated validation limits.

External References

Sources checked November 13, 2026. Broadcom links retain the program and product ID required to select the record. Dell links retain the GUID required to open the manual section and, where needed, the language selector.

• Broadcom: Unlocking AI Performance, Benefits and Certification of VMware AI ReadyNodes. November 12, 2026.
• Broadcom Compatibility Guide: AI Ready Node (Server + GPU). Select the exact server, GPU, release, and operating mode.
• NVIDIA: List of NVIDIA-Certified Systems. Dell R760 and XE9680 entries.
• Dell PowerEdge XE9680 Installation and Service Manual: GPU Specifications. HGX H200 hardware identity.
• Dell PowerEdge XE9680 Installation and Service Manual: Supported Operating Systems. OS-GPU compatibility matrix.
• NVIDIA Virtual GPU Software 21.0: VMware vSphere Release Notes. Manager and guest-driver compatibility.
• Broadcom: PowerEdge R760 VM DirectPath record. Gold 6400/5400; ESXi 9.1 L40 certificate 9183745.
• Broadcom R760 AI ReadyNode records: 55720, Gold 6400/5400; 58972, Platinum 8500; 59031, Gold 6500/5500.
• Broadcom XE9680 AI ReadyNode records: 58009, Platinum 8400; 60033, Platinum 8500. Select the ESXi release and its certification features.
• Dell PowerEdge R760 Installation and Service Manual: Expansion-Card Installation Guidelines. GPU quantity and riser configuration.
• Dell: PowerEdge Sets the Pace in MLPerf Inference v5.1. XE9680 with eight H200 SXM GPUs and ESXi 9.0.0.
• NVIDIA AI Enterprise 8.3: NVIDIA NVSwitch. Platform, profile, guest OS, and GPU allocation limits.

SRM Is Now Included in VCF and VVF: Turn the Licensing Change into a Recovery Plan

SRM is included in qualifying VCF and VVF subscriptions. Use this guide to confirm eligibility, obtain the interim key, plan for May…

The post VMware AI ReadyNode Certification: Why Server and GPU Compatibility Is Not Enough appeared first on Digital Thought Disruption.