You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
KubeVirt 1.8.2 VMIs stuck in Scheduled on Kubernetes 1.36 hosts (checksum int32 CRD validation) #2769
On a Cozystack v1.4.2 install whose host Kubernetes is v1.36, tenant Kubernetes clusters never come up: their VMs stay in Scheduled and virt-handler logs repeat:
... is invalid: <nil>: Invalid value: "": Checked value must be of type integer with format int32 in status.volumeStatus[N].containerDiskVolume.checksum
Root cause
This is upstream kubevirt/kubevirt#17858. KubeVirt's ContainerDiskInfo / KernelInfo / InitrdInfoChecksum field is a uint32, which the CRD renders as format: int32. Before Kubernetes 1.36 the API server silently stripped format: int32 from CRD schemas, so the field was never validated. Kubernetes 1.36 (kubernetes/kubernetes#136582) enabled strict numeric-format validation for CRDs, so the API server now rejects every virt-handler status update and the VMI never leaves Scheduled.
Cozystack v1.4.2 ships KubeVirt v1.8.2. The upstream fix (kubevirt/kubevirt#17469, Format:=int64 markers on the three Checksum fields) is only in main / v1.9.0-alpha.0 and is not backported to release-1.8. KubeVirt maintainers state that Kubernetes 1.36 is not officially supported by KubeVirt 1.8.
Impact
Any Cozystack install on a Kubernetes 1.36 host cannot create tenant clusters or VMs. Confirmed by multiple users on the community channel (bare-metal Talos + k8s 1.36 among them).
Options
Document that Kubernetes 1.36 hosts are not yet supported and install on <= 1.35 until a fixed KubeVirt is shipped.
Carry a CRD patch in the kubevirt-operator package (override the checksum format to int64, or drop the field) until a KubeVirt release with the fix is available.
Bump KubeVirt to a release that includes the fix once one exists on the 1.8 line, or move to 1.9.
Workaround (kubectl-only, from the upstream thread)
Field confirmation: a user hit this on a default install. The cozystack-shipped Talos v1.13.0 image (ghcr.io/cozystack/cozystack/talos:v1.13.0) defaults to Kubernetes 1.36.0, which deterministically breaks tenant VM creation with the bundled KubeVirt 1.8.2.
This is the default install path, not an opt-in to a bleeding-edge Kubernetes, so any v1.4.2 user bootstrapping on the shipped Talos 1.13 image is affected — tenant clusters never come up. Reporter's workaround is to pin Talos to 1.12.7 / 1.12.6 (k8s <= 1.35) until a KubeVirt with the fix ships.
Activity
lexfrei commentedon May 29, 2026
Upstream: kubevirt/kubevirt#17858. Fix kubevirt/kubevirt#17469 is in main / v1.9.0-alpha.0 only, not yet backported to release-1.8.
lexfrei commentedon May 29, 2026
Field confirmation: a user hit this on a default install. The cozystack-shipped Talos v1.13.0 image (
ghcr.io/cozystack/cozystack/talos:v1.13.0) defaults to Kubernetes 1.36.0, which deterministically breaks tenant VM creation with the bundled KubeVirt 1.8.2.This is the default install path, not an opt-in to a bleeding-edge Kubernetes, so any v1.4.2 user bootstrapping on the shipped Talos 1.13 image is affected — tenant clusters never come up. Reporter's workaround is to pin Talos to 1.12.7 / 1.12.6 (k8s <= 1.35) until a KubeVirt with the fix ships.
chore(kubernetes): refresh managed Kubernetes patch versions (#3014)
MichelJansen91 commentedon Jun 23, 2026
Aleksei Sviridkin (@lexfrei) The Kubevirt fix is now merged upstream and released with v1.8.4. So no reason to exclude k8s v1.36 anymore I guess
fix(kubevirt): update KubeVirt to v1.8.4 (cozystack#2940)