feat(gpu): name GPU classes in vm-instance and kubernetes-nodes - #5030

KubeVirt derives launcher requests from the admitted VMI and does not
allow another controller to change that spec afterwards. Class
resolution and offer validation must therefore finish at VMI creation. A
resource outside permittedHostDevices otherwise leaves a VMI Pending
without a pod. Resolving from uncached reads avoids admitting against an
obsolete class or entitlement; asynchronous class status cannot
establish resource-name uniqueness.

Capacity shortages belong to the scheduler: refusing admission would put
a VM into KubeVirt's retry backoff instead of starting it when a unit
frees up. Tenant-controlled per-unit expansion still needs a fixed
safety bound to prevent a small annotation from exhausting controller
memory.

A guest needs its class's license without embedding the token in an
image or changing which disk boots. Class tolerations must survive
LiveUpdate, which resets VMI tolerations from the VM template; the
launcher pod is the stable place to apply them. Migration and volume-
binding pods need the same scheduling access.

Assisted-by: LLM
Signed-off-by: Aleksei Sviridkin <[email protected]>

A replica must not receive fail-closed admission traffic until its
webhook server serves. Otherwise startup and rollout can block GPU VM
creation.

GPU resource names requested only by pods cannot always be inferred from
a class or the KubeVirt permitted-device table. The hoster needs a way
to identify them for admission.

Assisted-by: LLM
Signed-off-by: Aleksei Sviridkin <[email protected]>

Fail-closed GPU admission must remain available during controller
rollouts and node disruptions. Replicas sharing one node would fail
together, and an unready replica must not receive admission traffic.

The availability dependency must be limited to VMs using class entries.
Other VMs and pods should not wait for a GPU webhook they do not need.

Assisted-by: LLM
Signed-off-by: Aleksei Sviridkin <[email protected]>

A pod-only GPU resource may have no GPUClass or KubeVirt table entry.
The hoster needs to identify those resources explicitly so admission can
detect requests that bypass class entries. Commas in a name would
corrupt the controller's comma-separated flag; native resource names
would misclassify CPU or memory as GPUs.

A class reference is unusable where no GPU webhook will resolve it.
Charts need that cluster capability to refuse such inputs rather than
boot a VM without GPUs. Keeping the capability key absent while disabled
avoids unnecessary upgrades through the shared tenant values channel.

Assisted-by: LLM
Signed-off-by: Aleksei Sviridkin <[email protected]>

A tenant choosing an offer needs its availability and remaining budget
before submitting a VM, rather than discovering them through a refused
start. Reusing admission's pool calculation keeps the budget estimate
consistent with writes.

The catalog is visible to every authenticated user. Class-wide figures
provide the information needed to size an entry without disclosing node
identity or per-node inventory. An unentitled tenant cannot use a vGPU
offer even when its budget has room.

Assisted-by: LLM
Signed-off-by: Aleksei Sviridkin <[email protected]>

Tenants need to select an offer independently of the hoster's device-
plugin naming. Class references preserve that distinction when the
backend resource name changes.

Mixing raw GPU entries with class references would create two sources of
GPU requests on one VMI. A homogeneous list avoids that ambiguity. A
cluster without the resolving webhook must refuse references rather than
silently boot a VM without its requested GPUs.

Assisted-by: LLM
Signed-off-by: Aleksei Sviridkin <[email protected]>

Worker pools need the same GPU offers as individual VMs, with the
requested count applying to each worker. Existing pools on raw names
must retain their rendered configuration: a changed template hash would
unnecessarily replace their workers.

Talos needs the vendor's modules before a worker can use its devices.
The class's immutable vendor is suitable for this choice; a mutable
device-plugin resource name is not a reliable vendor identifier. An
unresolved class cannot provide a complete worker configuration.

Assisted-by: LLM
Signed-off-by: Aleksei Sviridkin <[email protected]>