GPU passthrough gives a VM direct access to a physical accelerator, constraining which lifecycle operations the hypervisor can perform. Which operations remain available depends on the destination platform, its implementation of that access mode, and the documented conditions for the release. A VMware exit plan that validates a GPU workload by booting it on the destination and comparing throughput to the source has tested the device. It has not tested the VM.
The two tests answer different questions. A workload that boots, loads its driver and matches the source host's numbers has shown that the device works. Whether that same VM can be live-migrated for host maintenance, snapshotted before a change, or restarted automatically after a host failure depends on how the device was attached and on what the destination documents for that attachment. Those are separate capabilities. A sourced statement about one says nothing about the others, and this post treats them that way throughout.
The decision here is narrow. The device-access mode constrains the lifecycle operations available to the VM, so it has to be evaluated per workload, before the destination is committed and before a cutover date is fixed. This is not a hardware compatibility checklist, and it does not claim to cover every hypervisor. Where the documentation is silent, or this review did not reach it, the text says so instead of filling the gap.
The device works. Which VM operations survive is a separate question.
Booting Is Not a Lifecycle Test
In virtualization architecture, a VM's lifecycle is the set of operations the platform performs on it without the workload's involvement. It moves for maintenance, it is captured before a change, and it comes back after a host fails. Migration validation checks that the workload runs. The lifecycle is what the operations team assumes the platform will keep doing for years afterward. Four operations are worth keeping apart.
- Live migration — moving a running VM to another host with no interruption, normally for planned maintenance or rebalancing.
- Snapshots and suspend/resume — separate capabilities, grouped here because they are often evaluated together during change and migration planning. Snapshot support does not establish suspend/resume support, or vice versa.
- HA restart — starting the VM on another host after an unplanned host failure. The VM restarts. It does not migrate.
- Placement and drain — where the scheduler may start the VM, and what happens to it when a host is drained for maintenance.
The distinction between live migration and HA restart matters most. A platform that restarts a VM on another node after a failure has provided recovery. It has not provided live migration, and a planned drain that restarts the VM is an interruption the maintenance window has to absorb. A runbook that says "migrate the VMs off the host before patching" assumes live migration. A recovery plan that says "the cluster will restart it" assumes HA restart. A VM can have one without the other, and the device-access mode is one of the things that decides which. GPU passthrough is where that dependency shows up first, because the device is attached directly to the guest.
Diagnostic: "Which of these four operations does this workload's maintenance, backup and recovery plan actually assume, and does its device-access mode provide each one on the destination?"
Direct Assignment, Mediated Access, and the Four Operations
Two device-access modes matter for GPU workloads: GPU passthrough and mediated access. The rest of this post keeps them separate. In direct assignment, which is what GPU passthrough means, the guest is given the physical device. Platforms name this PCI passthrough, DirectPath I/O or Discrete Device Assignment. In mediated or partitioned access, a vendor driver or the hypervisor presents a slice of the device to the VM, and some vendor-supported combinations document live migration under stated conditions. Whether a given combination does is a vendor-matrix question, and this review did not answer it. Treating the two modes as interchangeable is the error this post exists to prevent.
Other device types, such as NICs and SR-IOV functions, raise the same question. They are out of scope here and were not surveyed, and nothing below should be read as covering them.
The table records what this review established for each destination and mode. A sourced cell names its source in the section that follows. A cell marked "Not established" means the review did not find or verify a primary source for it. It is not a statement that the operation is unsupported.
What the documentation establishes, and where it stops.
| Destination and mode | Live migration | Snapshots / suspend-resume | HA restart | Placement and drain |
|---|---|---|---|---|
| vSphere, DirectPath I/O | Blocked (Broadcom) | Blocked (Broadcom) | Not established | Not established |
| Hyper-V, DDA (Windows Server 2025) | Not currently supported (Microsoft) | Not established | Restarts where pool GPU resources exist (Microsoft) | Drain restarts the VM on a node with pool resources (Microsoft) |
| Proxmox VE, PCI passthrough | Blocked (Proxmox guide) | Not established | Not established | Not established |
| Hyper-V, GPU partitioning | Not established | Not established | Not established | Not established |
| Proxmox VE, mediated devices | Not established | Not established | Not established | Not established |
| Nutanix AHV, any GPU mode | Not established | Not established | Not established | Not established |
| Vendor vGPU on any hypervisor | Not established | Not established | Not established | Not established |
What the Documentation Establishes About GPU Passthrough
Three destination-and-mode combinations have primary documentation behind them. Each is stated at the scope its source supports.
vSphere DirectPath I/O
Broadcom's knowledge base article Virtual Machine vMotion is not supported on PCI vSphere Direct Path I/O devices at the VM level is direct. When a PCI DirectPath I/O device is assigned to a VM, the VM cannot be live migrated, and snapshots and suspend/resume are blocked. The documented remedy is to shut the VM down and remove the device, after which vMotion works again. The article does not state which vSphere versions it applies to, so the exact build in the source environment is something to check, not assume. It also says nothing about HA restart. That cell stays open, because a restriction on live migration is not evidence about what happens after a host failure. For a VMware exit, this is the source-side baseline for VMs using PCI DirectPath I/O under the conditions the KB describes: live migration, snapshots and suspend/resume are unavailable. Do not generalize it to other GPU-access modes, or assume it applies to every vSphere build without checking the source environment.
Hyper-V Discrete Device Assignment
Microsoft's guidance for GPUs in clustered VMs is explicit about the split. DDA is Hyper-V's form of GPU passthrough. Live migration of VMs using GPUs provided by DDA isn't currently supported, but the cluster can restart those VMs and place them where GPU resources are available after a failure. Draining a server restarts the VM on another node that has sufficient resources in the GPU pool. The guidance applies to Windows Server 2025 and Azure Local 2311.2 and later, and DDA with GPU pools in clustered VMs requires Windows Server 2025 Datacenter edition.
For planned maintenance the consequence is concrete: the drain is a restart, so the maintenance window has to treat it as an interruption. Microsoft points to GPU partitioning as the alternative to investigate when live migration is required. The support conditions for that mode are covered separately and were not verified in this review, so no live-migration capability is claimed for the partitioning row.
Proxmox VE
The Proxmox VE administration guide states it plainly: PCI or USB devices that are passed through currently block live-migration. For GPU passthrough on Proxmox, that sentence is the sourced finding. The copy retrieved for this review was labeled version 9.2.13 and dated 24 September 2026, so confirm the version your destination runs. Proxmox also supports cluster-level resource mappings, which its PCI passthrough documentation says exist so mapped devices can be properly used with HA. That is a statement of design intent. It does not establish that a VM with a mapped GPU restarts cleanly after a node failure, and snapshot behavior for passthrough VMs was not established either.
This is also where Proxmox's operating assumptions diverge from vSphere's. Proxmox Isn't Replacing VMware. It's Replacing Assumptions. treats vMotion, snapshot semantics and HA clustering as VMware implementations of infrastructure primitives rather than primitives themselves. A passthrough VM is a case where the destination's implementation differs from the source's for a reason unrelated to the hypervisor's general design. The reason is the device-access mode.
⚠ Do Not Generalize: These findings apply to direct assignment. A restriction on GPU passthrough is not a restriction on GPUs, and a destination that blocks live migration for a passed-through device says nothing about its mediated or partitioned modes.
Where the Evidence Stops
Four items remain open for this review. None of them should be read as a negative finding.
Nutanix AHV. No primary AHV source was retrieved for this review, for either GPU passthrough or vGPU. The rolling-maintenance model described in Upgrade Physics: Designing for Rolling Maintenance Without Stopping Production relies on evacuating workloads before a host is maintained. Whether an AHV GPU workload can participate in that evacuation under its actual access mode is not established here. That determines whether it can follow the normal maintenance procedure or needs a separately validated one.
Proxmox mediated devices. Proxmox documents mediated devices, including vGPU, as devices created when the VM starts and removed when it stops. That describes lifecycle at the device level. The documentation read for this review does not say whether a VM with a mediated device can live-migrate, so no claim is made either way.
Vendor vGPU matrices. Any vGPU migration claim depends on the GPU vendor's current compatibility matrix and on the destination vendor's own documentation. Neither was retrieved for this review, so the post makes no vGPU migration claim for any destination.
Hyper-V GPU partitioning. Microsoft names it as the option when live migration is required. The supporting conditions were not verified, so the table leaves the row open.
The Migration-Gating Decision Model
The model has four steps, applied per workload, in order. It gates the cutover commitment. It is not a post-cutover validation.
01 — REQUIRED OPERATIONS
For each GPU workload, state which of the four operations its maintenance, backup and recovery plans require. Take this from the runbooks as written, not from what the platform is assumed to provide.
02 — ACTUAL ACCESS MODE
Record whether each VM uses GPU passthrough, a mediated mode or a partitioned mode in production today, from the hypervisor configuration and not from the procurement record.
03 — DESTINATION EVIDENCE
For that mode and each required operation, find the destination vendor's documentation for the exact release. Mark each cell sourced or not established. A cell that is not established is not a pass.
04 — DISPOSITION
Pass. Change the access mode. Substitute an operational procedure, such as a planned downtime window or restart-based recovery. Or leave it unresolved, which holds the workload out of the cutover commitment.
The fourth step is the one that changes plans. A workload whose required operation is not established on the preferred destination does not pass by default. It is held out of the cutover commitment until the evidence is in, and the plan carries a date for getting it. The gate sits ahead of the destination commitment for the same reason. If a required operation fails on the preferred destination for the workload's current mode, the answer might be a different mode, a different destination for that workload, or an operational substitute. All three are cheaper to choose before the target is fixed.
Four steps per workload, applied before the destination is committed.
This is a migration-planning gate, in the same family as the other pre-cutover work in the VMware Migration Strategy stage of the Virtualization Architecture Path. It belongs in the plan alongside that work.
What This Changes Before Target Selection
Two neighboring problems should not be confused with this one. The Hypervisor Is Not the Migration Target — The Operating Model Is covers governance, authority and policy that fail to transfer to a new platform. That gap exists whatever the workloads are doing. Device-access mode is a property of the individual workload that constrains what the platform can do for it, with governance fully in place. And Your VMware Exit Plan Assumed a Tool You Didn't Control covers an exit plan failing on access to the migration tooling itself. The shared lesson is that an exit plan's assumptions include things outside the destination's feature list. The device-access mode is one of them, and it lives in the workload.
The GPU workloads in an estate can be listed. The useful output of the model is a per-workload disposition: which move with the main wave, which move later behind the evidence, which move in a different mode, and which move with a planned interruption written into the cutover plan. That list exists before any destination is chosen, and it should shape the shortlist.
Architect's Verdict
GPU passthrough that works on the destination has passed a performance test. It has not passed a lifecycle test, and different things decide the two. The device-access mode constrains which lifecycle operations the VM can keep, and the destination's documentation for that mode and release determines whether each one is available.
The real problem is that migration validation measures the device and skips the operations. Live migration, snapshots, HA restart and drain are four separate capabilities, and sourced evidence about one is not evidence about the others. Where the evidence is missing, the honest status is not established. It is not "unsupported" and it is not "assumed."
Choose the access mode against the lifecycle the workload requires, before the destination is committed. Hold any workload whose required operation is not established out of the cutover commitment until it is. A VM that boots proves the device. It does not prove the lifecycle.
Originally published at rack2cloud.com
Top comments (0)