Harden vGPU release ordering in the instance lifecycle

[yummybomb]

Summary

Layer 2 of the vendor VFIO vGPU stack (#366 ← this ← #363 ← #364 ← #321). Where #366 is a behavior-preserving refactor, this layer changes lifecycle semantics — release ordering and retention — still on mdev-era machinery, before the vendor VFIO backend lands above:

• Delete releases the vGPU before other teardown — a failed release retains instance metadata while nothing destructive has happened to its attachments yet, so a retried delete stays safe. A successful release persists the cleared assignment before later teardown, and stopped instances retry a previously failed release.
• Stop keeps its no-op contract — a failed retained-release on stop logs and retains the assignment metadata instead of failing the stop; assignments are passed to DestroyVGPU as a struct.
• Forks don't inherit retained assignments — a retained (failed-release) vGPU assignment is stripped from fork metadata so a fork can't release its parent's device.
• Start persists a stale release immediately — releasing a stale assignment before start writes the cleared metadata at once, so a later start failure can't leave metadata pointing at a device that's already gone.

Testing

• go build ./..., go vet clean
• go test -race targeted lib/instances lifecycle suites pass

---

Note

Medium Risk
Changes delete/stop/start ordering and failure semantics for GPU host resources; incorrect ordering could leak vGPU slots or leave instances in a partially deleted state, but behavior is heavily tested and failures retain metadata for safe retries.

Overview
Hardens vGPU lifecycle semantics ahead of vendor VFIO work: release ordering, metadata retention when teardown fails, and fork/snapshot behavior so host GPU state cannot be double-freed or resurrected from stale snapshots.

Delete now blocks restart policy before teardown, releases vGPU before network/device/volume cleanup, fails the delete (keeping metadata) if release fails, and persists cleared assignment fields after a successful release. Stop no longer clears assignment metadata on a failed release—it logs and retains fields for retry; stop on an already-stopped instance retries a retained release via releaseRetainedVGPULocked. Start releases any stale retained assignment and saves metadata immediately before booting a new mdev.

Forks (forkInstance, forkSnapshot) strip live vGPU assignment from fork metadata (profile only); restore snapshot keeps the instance’s current assignment instead of the snapshot’s embedded copy. devices.DestroyVGPU takes a VGPUAssignment struct (framework, path, UUID) instead of separate parameters.

Lifecycle tests cover delete ordering, restart blocking on failed delete, fork/snapshot vGPU clearing, and stale-release persistence on start/stop.

^{Reviewed by Cursor Bugbot for commit cb55f3a. 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):

• 1c1f52e — dropped the HasMdev/IsAllocated() compatibility shim. VirtualFunction is internal and never serialized in an API response or persisted, so a single Allocated field is enough.

Kept as-is:

• the delete/stop behavior change (fail and retain assignment metadata when release fails) — orphan reconciliation only runs at startup, so failing the delete is the correct fail-closed behavior;
• the darwin DestroyVGPU unknown-framework error — it keeps the fail-closed rollback semantics identical on macOS, which the lib/instances tests exercise in CI.

Tests: go test -race ./lib/devices, ./lib/resources, ./lib/hypervisor/qemu, ./lib/hypervisor/cloudhypervisor, and the vGPU-targeted ./lib/instances tests all pass; the remaining lib/instances E2E failures require KVM/images and fail identically on an unmodified checkout.

[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 7b1f995. Configure here.}