feat(vm): add GPU DRA resource claim support

[danilrwx]

Description

Users running ML/rendering workloads can now attach a physical GPU to a virtual machine. Previously the VirtualMachine API had no way to request a GPU at all.

A new spec.gpus field lets a user request a GPU by naming a GPUClass (provided by the GPU module). The virtualization controller generates a DRA ResourceClaimTemplate per entry that targets the DeviceClass created by that GPUClass, marks the request for exclusive VFIO passthrough, and renders the corresponding DRA claims and GPU devices into the KubeVirt VM.

Highlights:

• VirtualMachine.spec.gpus[] with a single field gpuClassName, up to 16 entries; list order is not significant, and duplicate entries request several cards of the same class.
• A GPU feature gate (alpha, locked off in CE).
• Admission rejects GPU entries unless the GPU feature gate is enabled and the referenced GPUClass exists; the check runs only when GPUs are introduced or changed, so unrelated updates of an existing VM are never blocked.
• A GPUClassReady VM condition reports readiness: GPUClassNotFound when a class is missing (or its CRD is absent), GPUClassNotReady while the class is still initializing, GPUClassReady otherwise — instead of a silently pending claim.
• Changing spec.gpus on a running VM requires a restart to take effect (AwaitingRestartToApplyConfiguration); a VM with a GPU is non-migratable.
• Allocation and passthrough-safety constraints are also enforced in KubeVirt as a safety layer (depends on fix(dra): support Deckhouse GPU attributes 3p-kubevirt#130).

Why do we need it, and what problem does it solve?

ML and rendering workloads inside VMs need a real GPU. Until now there was no way to pass one through the VirtualMachine API.

Selecting a GPU by GPUClass keeps VM manifests portable: the user asks for a class (for example nvidia-h100) and lets DRA and the scheduler place the VM on a node with a suitable exclusive, passthrough-capable card, instead of pinning the VM to a specific node, PCI address, or GPU UUID. The selection policy (which SKU, whole card vs MIG, sharing, exclusivity) lives in the GPUClass owned by the GPU module, so it is not duplicated in the virtualization module.

What is the expected result?

1. Install a GPU DRA provider and create a GPUClass (for example nvidia-h100); the GPU module creates a DeviceClass with the same name.
2. Enable the GPU feature gate in ModuleConfig virtualization.
3. Create a VM with spec.gpus:

   spec:
     gpus:
       - gpuClassName: nvidia-h100

4. The controller creates a ResourceClaimTemplate, and the VM schedules on a node with a matching exclusive physical GPU passed through via VFIO.
5. If the GPUClass is missing or not yet ready, the VM reports GPUClassReady=False with a clear reason instead of hanging silently. Changing spec.gpus on a running VM applies only after a restart.

Checklist

• The code is covered by unit tests.
• e2e tests passed.
• Documentation updated according to the changes.
• Changes were tested in the Kubernetes cluster manually.

Changelog entries

section: core
type: feature
summary: "Attach a physical GPU to a virtual machine by naming a GPUClass in spec.gpus."