Integrate vendor VFIO vGPUs into the instance lifecycle

[yummybomb]

Summary

Top layer of the vendor VFIO vGPU stack (generalize-vgpu-device #322 ← hypervisor-liveness #363 ← vendor-vfio-backend #364 ← this). The backend itself is in #364; this layer wires it into the instance lifecycle and adds the release guards that make reusable-VF assignments safe:

• Live-instance claim guard on release — an assignment goes stale when its release succeeds but the metadata save does not (or start fails between the release and its first save). Since vendor VFIO reuses the same VF path across assignments, honoring a stale claim could clear a VF out from under the live instance that owns it now. Every release consults live instance metadata (liveness verified via Harden hypervisor process liveness checks #363's socket-ownership check) and drops stale metadata without touching the device.
• Assignment durability — assignments are tagged with the owning instance ID, persisted before booting a started instance, and retained in metadata when rollback release fails in create/start so later release paths can still find the device.
• Fail-closed startup reconciliation — the protected set of live VFs is built from ListInstancesForReconcile, which fails on any unreadable metadata instead of silently skipping it; when the inventory is unavailable, vendor VFIO reconciliation is skipped entirely while mdev reconciliation still runs.

Testing

• go build ./..., go vet ./... clean
• go test -race passes for lib/instances targeted suites, lib/devices, lib/resources, lib/builds (TestCreateInstanceWithNetwork needs image pulls + iptables and fails in this environment on the unmodified base as well)

---

Note

High Risk
Changes GPU release and startup reconciliation for vendor VFIO; incorrect claim detection or protected-set building could detach GPUs from live VMs or leave orphans.

Overview
Wires vendor VFIO vGPUs into create/start/stop/delete with safety around reused VF paths: releases go through releaseStoredVGPU on the manager, tag assignments with instance ID, and skip DestroyVGPU when another live instance (socket + PID liveness) already claims the same GPUDevicePath—only clearing stale metadata.

Durability on failure: failed create cleanup can retain GPU fields on disk instead of wiping the guest dir; start persists metadata after vGPU creation and on failed rollback destroy; create/start cleanup paths mirror that retention behavior.

Startup reconcile: API startup builds a protected set of VF paths from ListInstancesForReconcile (strict inventory—invalid metadata fails the list) and passes it to devices.ReconcileVGPUs instead of bare mdev reconcile; if listing fails, vendor VFIO reconciliation is skipped (warn) while other paths still run.

Adds ListInstancesForReconcile on the instance manager (vs list skipping bad metadata) and tests for stale-claim delete, retained failed-create metadata, and reconcile list strictness.

^{Reviewed by Cursor Bugbot for commit 23fb2f5. Bugbot is set up for automated code reviews on this repo. Configure here.}

[yummybomb]

Trimmed over-engineering after an architectural review against the parent task (host kernel 6.8 / Ubuntu 24.04 support). Most of the removed weight came from earlier review-round additions rather than the original design:

[cursor]

Cursor Bugbot has reviewed your changes using high effort and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit 23fb2f5. Configure here.}

[cursor]

Release claim check skips bad metadata

High Severity

The vgpuAssignmentClaimedByLiveInstance check uses listInstances, which skips unreadable metadata. This differs from the fail-closed ListInstancesForReconcile used by startup protection. If a live instance's metadata is unreadable, the claim check can miss, leading releaseStoredVGPU to destroy a vGPU still in use by that live instance.

 

^{Reviewed by Cursor Bugbot for commit 23fb2f5. Configure here.}