api: validate VMI checksum status fields as uint32 range by oshoval · Pull Request #17469 · kubevirt/kubevirt

oshoval · 2026-04-12T11:18:20Z

What this PR does

Before this PR:

VMI checksum status fields were validated as int32 in generated CRD schema.
Valid checksum values above 2147483647 could be rejected during status updates.

After this PR:

Checksum validation is defined on API fields (kernelInfo, initrdInfo, containerDiskVolume) using kubebuilder markers.
Generated schema validates these fields as int64 with explicit uint32 bounds (0..4294967295).

Why we need it and why it was done in this way

Without it, VMs failed to start locally, due to checksum being bigger than max int32.

{"component":"virt-handler","controller":"vm","kind":"","level":"error","msg":"Updating the VirtualMachineInstance status failed.","name":"testvmi-txhzt-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx","namespace":"kubevirt-test-default1","pos":"vm.go:1531","reason":"VirtualMachineInstance.kubevirt.io \"testvmi-txhzt-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx\" is invalid: <nil>: Invalid value: \"\": Checked value must be of type integer with format int32 in status.volumeStatus[1].containerDiskVolume.checksum","timestamp":"2026-04-12T07:21:26.636683Z","uid":"3cdb6cfd-6186-4916-9548-2d32de8395ab"}

Release note

None

kubevirt-bot · 2026-04-12T11:18:25Z

Skipping CI for Draft Pull Request.
If you want CI signal for your change, please convert it to an actual PR.
You can still manually trigger a test run with /test all

VMI checksum status fields are uint32, but generated CRD validation used int32, which could reject valid large checksum values and fail status updates. Define checksum validation on the API fields via kubebuilder markers and regenerate outputs so checksum schema uses int64 with explicit uint32 bounds. Assisted-by: Cursor Signed-off-by: Or Shoval <[email protected]>

sourcery-ai

Hey - I've found 1 issue

Prompt for AI Agents

Please address the comments from this code review:

## Individual Comments

### Comment 1
<location path="staging/src/kubevirt.io/api/core/v1/types.go" line_range="407-409" />
<code_context>

 // KernelInfo show info about the kernel image
 type KernelInfo struct {
+	// +kubebuilder:validation:Format:=int64
+	// +kubebuilder:validation:Minimum:=0
+	// +kubebuilder:validation:Maximum:=4294967295
 	// Checksum is the checksum of the kernel image
 	Checksum uint32 `json:"checksum,omitempty"`
</code_context>
<issue_to_address>
**issue (bug_risk):** Kubebuilder marker syntax uses `=` rather than `:=`, which may prevent these validations from being applied.

Using `:=` instead of `=` for these validation markers (`Format`, `Minimum`, `Maximum`) will likely cause controller-tools to skip them when generating CRDs. Please update all affected markers (including those on `KernelInfo`, `InitrdInfo`, and `ContainerDiskInfo`) to use `=` so the schema validations are applied as intended.
</issue_to_address>

Sourcery is free for open source - if you like our reviews please consider sharing them ✨

_{Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.}

oshoval · 2026-04-12T12:51:24Z

https://prow.ci.kubevirt.io/view/gs/kubevirt-prow/pr-logs/pull/kubevirt_kubevirt/17469/pull-kubevirt-goveralls/2043296579464466432

/test pull-kubevirt-goveralls

enp0s3 · 2026-04-13T11:26:01Z

@oshoval Hi, the error message:

<nil>: Invalid value: "": Checked value must be of type integer with format int32

Is a bit misleading, are you sure it was an issue related to overflow rather than checksum with 0 value?

enp0s3

@oshoval Why do we need a release note here?

oshoval · 2026-04-13T11:39:57Z

@oshoval Hi, the error message:
<nil>: Invalid value: "": Checked value must be of type integer with format int32
Is a bit misleading, are you sure it was an issue related to overflow rather than checksum with 0 value?

You are right the print is misleading, but the value was indeed > max int32, while lower than max unit32
Reason according AI:

kube-openapi builds the detail string: Checked value must be of type integer with format int32 ....
apiextensions-apiserver wraps that detail with field.Invalid(fldPath, "", err.Error()), which hardcodes an empty bad value in this path.
Result: logs show Invalid value: "" even when the real value is non-empty and out of range.

0 was and still valid value according the manifest, it aint the problem

without the fix, failed 2/2, with fix pass always
see please manifest it verify int32, which cksum is unsigned crc32

max int32 = 2,147,483,647
max uint32 = 4,294,967,295
and i had 3,716,838,723

will drop the release note, not crucial - done

enp0s3 · 2026-04-14T03:58:45Z

/approve

kubevirt-bot · 2026-04-14T03:58:55Z

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: enp0s3

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Details

Needs approval from an approver in each of these files:

~~OWNERS~~ [enp0s3]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

oshoval · 2026-04-14T07:10:28Z

Thanks Igor

oshoval · 2026-04-15T08:05:15Z

Hi @lyarwood @0xFelix
would you able to review please ?

0xFelix

I want to point at #16708

But to me this change is fine...

/lgtm
/hold To give chance for others to jump in

kubevirt-commenter-bot · 2026-04-15T13:43:57Z

Required labels detected, running phase 2 presubmits:
/test pull-kubevirt-e2e-k8s-1.34-windows2016
/test pull-kubevirt-e2e-kind-1.35-vgpu
/test pull-kubevirt-e2e-kind-sriov
/test pull-kubevirt-e2e-k8s-1.35-ipv6-sig-network
/test pull-kubevirt-e2e-k8s-1.34-sig-network
/test pull-kubevirt-e2e-k8s-1.34-sig-storage
/test pull-kubevirt-e2e-k8s-1.34-sig-compute
/test pull-kubevirt-e2e-k8s-1.34-sig-operator

oshoval · 2026-04-15T14:04:40Z

thanks, do we really need the hold ?

if some one would like he has time until the CI finish, and worst case we can create follow-up please imho

0xFelix · 2026-04-17T07:34:23Z

/hold cancel

kubevirt-commenter-bot · 2026-04-17T10:05:33Z

/retest-required
This bot automatically retries required jobs that failed/flaked on
required test lanes of PRs.
Silence the bot with an /lgtm cancel or /hold comment for consistent failures.

xpivarc · 2026-04-24T12:56:52Z

+                  maximum: 4294967295
+                  minimum: 0


Is the maximum required?

The status field is uint32, but CRD schema expresses it as int64, so we explicitly constrain it to 0..4294967295 to preserve the API contract, in explicit way.

This also future-proofs the schema: if checksum generation changes later, validation will still enforce the expected uint32 range instead of silently accepting out-of-range values.

a7i · 2026-05-19T17:43:33Z

/cherry-pick release-1.8

kubevirt-bot · 2026-05-19T17:43:43Z

@a7i: only kubevirt org members may request cherry picks. If you are already part of the org, make sure to change your membership to public. Otherwise you can still do the cherry-pick manually.

Details

In response to this:

/cherry-pick release-1.8

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

Reverts b767b9c. The helper was added to work around what looked like the virt-handler containerdisk-socket race on k8s 1.36, but the actual root cause is unrelated: k8s 1.36's stricter CRD numeric format validation (kubernetes/kubernetes#136582) rejects VMI status updates with the pre-fix uint32 Checksum schema. See kubevirt/kubevirt#17858 for the upstream context and kubevirt/kubevirt#17469 for the upstream fix (merged to main, included in v1.9.0-alpha.0, not in v1.8.x). The follow-up commit bumps KUBEVIRT_VERSION so the test consumes a KubeVirt release that contains the fix, which removes the need for any test-side retry.

KubeVirt v1.8.2 publishes VMI status checksum fields (uint32 in Go) as format: int32 in its generated CRD schema. k8s 1.36 enables strict numeric format validation in CRDs via kubernetes/kubernetes#136582, which now rejects the legacy schema and causes virt-handler to enter an infinite VMI status update re-enqueue loop. Live migrations never complete and the descheduler e2e TestLiveMigrationInBackground times out. The schema fix landed upstream in kubevirt/kubevirt#17469 (merged to main on 2026-04-18, included in v1.9.0-alpha.0 tagged 2026-05-11) but was not backported to release-1.8, so no v1.8.x release contains it. Bump the default KUBEVIRT_VERSION to v1.9.0-alpha.0 so the e2e suite consumes a release whose generated CRDs are compatible with k8s 1.36's stricter validator. Tracked in kubevirt/kubevirt#17858.

fossedihelm · 2026-06-05T09:04:26Z

/cherrypick release-1.8

kubevirt-bot · 2026-06-05T09:06:21Z

@fossedihelm: new pull request created: #18055

Details

In response to this:

/cherrypick release-1.8

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

oshoval force-pushed the crd branch from 643bd45 to 30d7db5 Compare April 12, 2026 11:50

oshoval changed the title ~~crd-validation-generator: fix VMI checksum fields to uint32-compatible~~ api: validate VMI checksum status fields as uint32 range Apr 12, 2026

kubevirt-bot added release-note Denotes a PR that will be considered when it comes time to generate release notes. and removed release-note-none Denotes a PR that doesn't merit a release note. labels Apr 12, 2026

oshoval force-pushed the crd branch from 30d7db5 to e78c814 Compare April 12, 2026 11:51

oshoval marked this pull request as ready for review April 12, 2026 11:53

kubevirt-bot removed the do-not-merge/work-in-progress Indicates that a PR should not merge because it is a work in progress. label Apr 12, 2026

kubevirt-bot requested review from lyarwood and vladikr April 12, 2026 11:54

dosubot Bot added the area/api-server label Apr 12, 2026

sourcery-ai Bot reviewed Apr 12, 2026

View reviewed changes

Comment thread staging/src/kubevirt.io/api/core/v1/types.go Resolved

enp0s3 reviewed Apr 13, 2026

View reviewed changes

kubevirt-bot added release-note-none Denotes a PR that doesn't merit a release note. and removed release-note Denotes a PR that will be considered when it comes time to generate release notes. labels Apr 13, 2026

kubevirt-bot added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label Apr 14, 2026

0xFelix reviewed Apr 15, 2026

View reviewed changes

kubevirt-bot added the do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. label Apr 15, 2026

kubevirt-bot assigned 0xFelix Apr 15, 2026

kubevirt-bot added the lgtm Indicates that a PR is ready to be merged. label Apr 15, 2026

kubevirt-bot removed the do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. label Apr 17, 2026

kubevirt-bot merged commit 7c1fae3 into kubevirt:main Apr 18, 2026
43 checks passed

xpivarc reviewed Apr 24, 2026

View reviewed changes

0xFelix mentioned this pull request May 5, 2026

vmi: fix VSOCK CID schema mismatch causing VMI requeue loop #17690

Merged

9 tasks

dosubot Bot mentioned this pull request May 19, 2026

VMI status update loop on k8s 1.36: ContainerDiskInfo/KernelInfo/InitrdInfo Checksum (uint32) hit strict CRD format validation #17858

Closed

This was referenced May 29, 2026

KubeVirt 1.8.2 VMIs stuck in Scheduled on Kubernetes 1.36 hosts (checksum int32 CRD validation) cozystack/cozystack#2769

Closed

fix(kubernetes): add config_path patch for containerd 2.x cozystack/cozystack#2723

Merged

kubevirt-bot mentioned this pull request Jun 5, 2026

[release-1.8] api: validate VMI checksum status fields as uint32 range #18055

Merged

Conversation

oshoval commented Apr 12, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

What this PR does

Before this PR:

After this PR:

Why we need it and why it was done in this way

Release note

Uh oh!

kubevirt-bot commented Apr 12, 2026

Uh oh!

sourcery-ai Bot left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

oshoval commented Apr 12, 2026

Uh oh!

enp0s3 commented Apr 13, 2026

Uh oh!

enp0s3 left a comment

Choose a reason for hiding this comment

Uh oh!

oshoval commented Apr 13, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

enp0s3 commented Apr 14, 2026

Uh oh!

kubevirt-bot commented Apr 14, 2026

Uh oh!

oshoval commented Apr 14, 2026

Uh oh!

oshoval commented Apr 15, 2026

Uh oh!

0xFelix left a comment

Choose a reason for hiding this comment

Uh oh!

kubevirt-commenter-bot commented Apr 15, 2026

Uh oh!

oshoval commented Apr 15, 2026

Uh oh!

0xFelix commented Apr 17, 2026

Uh oh!

kubevirt-commenter-bot commented Apr 17, 2026

Uh oh!

Uh oh!

xpivarc Apr 24, 2026

Choose a reason for hiding this comment

Uh oh!

oshoval Apr 25, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

a7i commented May 19, 2026

Uh oh!

kubevirt-bot commented May 19, 2026

Uh oh!

fossedihelm commented Jun 5, 2026

Uh oh!

kubevirt-bot commented Jun 5, 2026

Uh oh!

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

8 participants

oshoval commented Apr 12, 2026 •

edited

Loading

oshoval commented Apr 13, 2026 •

edited

Loading

oshoval Apr 25, 2026 •

edited

Loading