Repository navigation
vm-instance: resources.cpu and resources.sockets accept quantity strings for integer-only fields, and a fractional value silently becomes one core #4104
Description
The vm-instance schema types resources.cpu and resources.sockets with the full Kubernetes quantity grammar, so 500m, .5 and 1e3 all validate. Both fields end up in domain.cpu.cores and domain.cpu.sockets, which are integers. A quantity that is not a whole number casts to 0, KubeVirt defaults a zero core count to 1, and the user gets a one-core VM with no error anywhere.
Two things follow from that, and they are the same root cause seen from different sides.
The user-visible half: with no instance type set and resources: {cpu: 500m, sockets: 1, memory: 8Gi}, the chart renders domain.cpu.cores: 0 and the VM boots with one core. Nothing reports it. This predates the instance-type work for #2909 and is unchanged by it; the test at packages/apps/vm-instance/tests/instancetype_resources_test.yaml:331 pins the behaviour and names it pre-existing.
The maintenance half: because the schema admits values that truncate, the chart has to carry machinery to detect them. The instance-type guard added for #2909 has to distinguish "sized" from "emits nothing so nothing conflicts", and it exists in that shape only because a quantity string can look like sizing and produce none.
Tightening both fields to integers deletes the class rather than working around it. The cost is a migration: any release carrying a quantity string in those fields would fail validation on upgrade, so it needs a deprecation path rather than a schema edit. That is why it was kept out of the PR that found it.
Worth deciding together with it: whether a fractional or sub-unit value should be rejected outright or rounded with a warning, since silently becoming one core is the behaviour nobody would choose deliberately.
Activity
lexfrei commentedon Sep 7, 2026
Another instance of the same schema-versus-template mismatch, on the memory field rather than cpu, and it fails in the opposite direction: instead of truncating to a value nobody wanted, it passes a guard nobody meant it to pass.
resources.memory: "0"written as a string is truthy in Go templates, soand .Values.resources .Values.resources.memoryaccepts it, the memory key is emitted, and the VM getsrequests.memory: "0". The same value written as the number0is falsy and is dropped by that guard, so the two spellings of the same quantity take opposite paths. The schema types the field as a quantity string, which is what makes the truthy spelling the natural one to write.That puts three shapes under one root.
cpu: 500mtruncates tocores: 0because the template converts a quantity to an integer.memory: "0"survives a truthiness guard that a numeric zero would not. And a negative quantity passes the schema pattern in the first place, which is recorded elsewhere as a repo-wide property of the generator'squantitytype rather than a property of this chart.The common cause is that the schema describes the Kubernetes quantity grammar while the templates handle a much smaller language, and nothing reconciles the two. Tightening the fields that must be whole numbers to integers, as this issue proposes, removes the first two outright: there is no truncation because there is nothing to truncate, and no string-versus-number asymmetry because the type admits one spelling.
Worth deciding here rather than separately, since a fix that only addresses truncation would leave the
"0"path standing.fix(vm-instance): let complete resources replace the instance type (#…
fix(vm-instance)!: refuse resources that cannot size the VM (cozystac…