vm-instance renders both instancetype matcher and explicit domain resources — KubeVirt rejects the VM with a conflict error #2909

Summary

Creating a VM with explicit resources (cpu/sockets/memory) instead of an instanceType is effectively impossible from the dashboard, and the error is misleading: the chart renders both the instancetype matcher and explicit domain resources, which the KubeVirt admission webhook rejects with a conflict error. Reported in the community chat on v1.4.2; the relevant templates are identical on main.

Symptom

A user clears the instanceType field in the dashboard form and sets cpu/ram, then gets a KubeVirt error complaining that the resource fields conflict with the selected instance type — from the user's perspective the instance type "never disappears".

Mechanism

1. packages/apps/vm-instance/values.yaml ships a non-empty default instanceType: "u1.medium". Clearing the field in the dashboard removes the key from user values, which just re-enables the chart default — "no instance type" cannot be expressed by omitting the key; only an explicit instanceType: "" works, which the form does not produce.
2. The virtual-machine.domainResources helper (packages/apps/vm-instance/templates/_helpers.tpl) renders domain.cpu and domain.resources from .Values.resources unconditionally, without checking instanceType.
3. The validation in templates/vm.yaml only enforces "at least one of instanceType / resources", not mutual exclusion, so a VM carrying both the spec.instancetype matcher and explicit spec.template.spec.domain.cpu / resources gets rendered.
4. KubeVirt's VM admission webhook rejects such a VM with a "conflicts with the selected instance type" error, which surfaces to the user as a confusing failure unrelated to anything they can fix from the form.

Proposed fix

1. Make the relationship explicit: either fail with a clear message when both instanceType and fully-specified resources are set, or let fully-specified resources take precedence and skip the instancetype matcher.
2. Consider whether the non-empty u1.medium default belongs in the chart at all, since any non-empty default makes "no instance type" inexpressible from schema-generated forms.

Related

The missing instance-type dropdown in the 1.4 dashboard is a separate, already-addressed concern: on main the instanceType schema field carries x-cozystack-options: {source: instancetype} (#2778), so the dropdown returns in v1.5.

Workaround

Set instanceType: "" explicitly (empty string, not key removal) together with full resources (cpu, sockets, memory — sockets is required too).