chore(kubevirt-operator): update to v1.8.2 - #2502
Conversation
Update KubeVirt operator from v1.6.3 to v1.8.2: - Update release version in Makefile - Refresh operator manifest with new CRD fields - Remove standalone ServiceMonitor and alerts templates Signed-off-by: IvanHunters <[email protected]>
Summary of ChangesHello, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed! This pull request upgrades the KubeVirt operator to version 1.8.2. The changes include significant updates to the operator's CRD to support new features like changed block tracking and improved architectural configurations. Additionally, the deployment manifests have been updated to better align with standard Kubernetes practices, and redundant monitoring templates have been removed in favor of the integrated operator manifest. Highlights
🧠 New Feature in Public Preview: You can now enable Memory to help Gemini Code Assist learn from your team's feedback. This makes future code reviews more consistent and personalized to your project's style. Click here to enable Memory in your admin console. Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on Gemini (@gemini-code-assist) comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for GitHub and other Google products, sign up here. Footnotes
|
📝 WalkthroughWalkthroughThe KubeVirt operator is upgraded from v1.6.3 to v1.8.2. The CRD schema is extended with new configuration fields ( Changes
Estimated code review effort🎯 4 (Complex) | ⏱️ ~45 minutes Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
Actionable comments posted: 2
🧹 Nitpick comments (1)
packages/system/kubevirt-operator/templates/kubevirt-operator.yaml (1)
1-8612: Vendor this system component throughcharts/, not a raw manifest intemplates/.This package still updates a rendered upstream manifest directly under
templates/, which diverges from the requiredpackages/system/**umbrella layout and makes future rebases/manual patches harder to manage.As per coding guidelines, "Follow Helm Charts umbrella pattern with vendored upstream charts in
charts/subdirectory for system components charts inpackages/system/".🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@packages/system/kubevirt-operator/templates/kubevirt-operator.yaml` around lines 1 - 8612, The PR added a large upstream manifest (CustomResourceDefinition, PriorityClass, ClusterRole/Role/Bindings, ServiceAccount, Deployment named "virt-operator", etc.) directly under templates/ (templates/kubevirt-operator.yaml); move this component into a vendored Helm chart under charts/ following the packages/system Helm umbrella pattern by creating a new chart (Chart.yaml, values.yaml) that contains the kubevirt resources as templates and values (e.g., VIRT_OPERATOR_IMAGE, replicas, namespace) and update the package to reference that chart instead of the raw manifest; remove the original templates/kubevirt-operator.yaml and ensure package metadata (values/helm chart list) points to the new charts/* entry so future upstream rebases are done by updating the vendored chart rather than editing raw manifests.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@packages/system/kubevirt-operator/Makefile`:
- Line 9: Update the single-line comment "# v1.7.0 blocked by
https://github.com/kubevirt/kubevirt/issues/16386" to a short explanatory note
stating why the Makefile now references v1.8.2 despite the issue remaining open:
either explain how v1.8.2 mitigates the problem, document that the risk is
accepted and why, or point to the evaluation/decision that led to skipping
v1.7.x (include the issue link and any brief mitigation/acceptance rationale).
Keep it concise and place the updated comment where the original line appears so
reviewers can see the rationale for choosing v1.8.2.
In `@packages/system/kubevirt-operator/templates/kubevirt-operator.yaml`:
- Around line 249-350: The packaged KubeVirt CR is missing the new
changedBlockTrackingLabelSelectors field, so changed-block-tracking (CBT) won't
be enabled after upgrade; update the packaged KubeVirt manifest's spec to
include changedBlockTrackingLabelSelectors and configure either
namespaceLabelSelector or virtualMachineLabelSelector to the desired scope
(e.g., matchLabels or matchExpressions that enable CBT for all VMs or specific
namespaces/VM labels). Locate the packaged KubeVirt CR manifest (the bundled
KubeVirt instance) and add a changedBlockTrackingLabelSelectors block matching
the schema (properties namespaceLabelSelector/virtualMachineLabelSelector with
matchLabels or matchExpressions) so CBT is enabled by default. Ensure the symbol
name changedBlockTrackingLabelSelectors exactly matches the schema added in the
CRD.
---
Nitpick comments:
In `@packages/system/kubevirt-operator/templates/kubevirt-operator.yaml`:
- Around line 1-8612: The PR added a large upstream manifest
(CustomResourceDefinition, PriorityClass, ClusterRole/Role/Bindings,
ServiceAccount, Deployment named "virt-operator", etc.) directly under
templates/ (templates/kubevirt-operator.yaml); move this component into a
vendored Helm chart under charts/ following the packages/system Helm umbrella
pattern by creating a new chart (Chart.yaml, values.yaml) that contains the
kubevirt resources as templates and values (e.g., VIRT_OPERATOR_IMAGE, replicas,
namespace) and update the package to reference that chart instead of the raw
manifest; remove the original templates/kubevirt-operator.yaml and ensure
package metadata (values/helm chart list) points to the new charts/* entry so
future upstream rebases are done by updating the vendored chart rather than
editing raw manifests.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
Run ID: 0e8b3a6c-b008-4196-81ad-d7de7fa9766f
📒 Files selected for processing (4)
packages/system/kubevirt-operator/Makefilepackages/system/kubevirt-operator/templates/ServiceMonitor.yamlpackages/system/kubevirt-operator/templates/alerts.yamlpackages/system/kubevirt-operator/templates/kubevirt-operator.yaml
💤 Files with no reviewable changes (2)
- packages/system/kubevirt-operator/templates/alerts.yaml
- packages/system/kubevirt-operator/templates/ServiceMonitor.yaml
| @@ -7,7 +7,7 @@ update: | |||
| rm -rf templates | |||
| mkdir templates | |||
| # v1.7.0 blocked by https://github.com/kubevirt/kubevirt/issues/16386 | |||
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Description: Check the status of the GitHub issue that blocked v1.7.0
gh issue view 16386 --repo kubevirt/kubevirt --json state,title,closedAt,urlRepository: cozystack/cozystack
Length of output: 282
Expand the comment to clarify why v1.8.2 is being adopted despite the blocking issue remaining open.
GitHub issue #16386 that blocked v1.7.0 is still OPEN and unresolved. Since this PR jumps to v1.8.2 (skipping v1.7.x entirely), the comment on line 9 should clarify the rationale—either explain how v1.8.2 mitigates the issue, document it as an accepted risk, or provide additional context for this version choice.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@packages/system/kubevirt-operator/Makefile` at line 9, Update the single-line
comment "# v1.7.0 blocked by https://github.com/kubevirt/kubevirt/issues/16386"
to a short explanatory note stating why the Makefile now references v1.8.2
despite the issue remaining open: either explain how v1.8.2 mitigates the
problem, document that the risk is accepted and why, or point to the
evaluation/decision that led to skipping v1.7.x (include the issue link and any
brief mitigation/acceptance rationale). Keep it concise and place the updated
comment where the original line appears so reviewers can see the rationale for
choosing v1.8.2.
| changedBlockTrackingLabelSelectors: | ||
| description: |- | ||
| ChangedBlockTrackingLabelSelectors defines label selectors. VMs matching these selectors will have changed block tracking enabled. | ||
| Enabling changedBlockTracking is mandatory for performing storage-agnostic backups and incremental backups. | ||
| nullable: true | ||
| properties: | ||
| namespaceLabelSelector: | ||
| description: NamespaceSelector will enable changedBlockTracking | ||
| on all VMs running inside namespaces that match the label | ||
| selector. | ||
| properties: | ||
| matchExpressions: | ||
| description: matchExpressions is a list of label selector | ||
| requirements. The requirements are ANDed. | ||
| items: | ||
| description: |- | ||
| A label selector requirement is a selector that contains values, a key, and an operator that | ||
| relates the key and values. | ||
| properties: | ||
| key: | ||
| description: key is the label key that the selector | ||
| applies to. | ||
| type: string | ||
| operator: | ||
| description: |- | ||
| operator represents a key's relationship to a set of values. | ||
| Valid operators are In, NotIn, Exists and DoesNotExist. | ||
| type: string | ||
| values: | ||
| description: |- | ||
| values is an array of string values. If the operator is In or NotIn, | ||
| the values array must be non-empty. If the operator is Exists or DoesNotExist, | ||
| the values array must be empty. This array is replaced during a strategic | ||
| merge patch. | ||
| items: | ||
| type: string | ||
| type: array | ||
| x-kubernetes-list-type: atomic | ||
| required: | ||
| - key | ||
| - operator | ||
| type: object | ||
| type: array | ||
| x-kubernetes-list-type: atomic | ||
| matchLabels: | ||
| additionalProperties: | ||
| type: string | ||
| description: |- | ||
| matchLabels is a map of {key,value} pairs. A single {key,value} in the matchLabels | ||
| map is equivalent to an element of matchExpressions, whose key field is "key", the | ||
| operator is "In", and the values array contains only "value". The requirements are ANDed. | ||
| type: object | ||
| type: object | ||
| x-kubernetes-map-type: atomic | ||
| virtualMachineLabelSelector: | ||
| description: VirtualMachineSelector will enable changedBlockTracking | ||
| on all VMs that match the label selector. | ||
| properties: | ||
| matchExpressions: | ||
| description: matchExpressions is a list of label selector | ||
| requirements. The requirements are ANDed. | ||
| items: | ||
| description: |- | ||
| A label selector requirement is a selector that contains values, a key, and an operator that | ||
| relates the key and values. | ||
| properties: | ||
| key: | ||
| description: key is the label key that the selector | ||
| applies to. | ||
| type: string | ||
| operator: | ||
| description: |- | ||
| operator represents a key's relationship to a set of values. | ||
| Valid operators are In, NotIn, Exists and DoesNotExist. | ||
| type: string | ||
| values: | ||
| description: |- | ||
| values is an array of string values. If the operator is In or NotIn, | ||
| the values array must be non-empty. If the operator is Exists or DoesNotExist, | ||
| the values array must be empty. This array is replaced during a strategic | ||
| merge patch. | ||
| items: | ||
| type: string | ||
| type: array | ||
| x-kubernetes-list-type: atomic | ||
| required: | ||
| - key | ||
| - operator | ||
| type: object | ||
| type: array | ||
| x-kubernetes-list-type: atomic | ||
| matchLabels: | ||
| additionalProperties: | ||
| type: string | ||
| description: |- | ||
| matchLabels is a map of {key,value} pairs. A single {key,value} in the matchLabels | ||
| map is equivalent to an element of matchExpressions, whose key field is "key", the | ||
| operator is "In", and the values array contains only "value". The requirements are ANDed. | ||
| type: object | ||
| type: object | ||
| x-kubernetes-map-type: atomic | ||
| type: object |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
set -euo pipefail
rg -n -C3 \
--glob '!packages/system/kubevirt-operator/templates/kubevirt-operator.yaml' \
'kind:\s*KubeVirt|changedBlockTrackingLabelSelectors' packagesRepository: cozystack/cozystack
Length of output: 487
🏁 Script executed:
cat -n packages/system/kubevirt/templates/kubevirt-cr.yamlRepository: cozystack/cozystack
Length of output: 1195
🏁 Script executed:
wc -l packages/system/kubevirt/templates/kubevirt-cr.yaml
rg -n 'changedBlockTrackingLabelSelectors' packages/system/kubevirt/templates/kubevirt-cr.yamlRepository: cozystack/cozystack
Length of output: 118
🏁 Script executed:
sed -n '3695,3796p' packages/system/kubevirt-operator/templates/kubevirt-operator.yaml | head -50Repository: cozystack/cozystack
Length of output: 3180
🏁 Script executed:
rg -n 'changedBlockTrackingLabelSelectors' packages/system/kubevirt/ --type yamlRepository: cozystack/cozystack
Length of output: 45
The new changedBlockTrackingLabelSelectors field is not set in the packaged KubeVirt CR.
While the schema additions at lines 249–350 and 3695–3796 make this field valid, the packaged KubeVirt instance in packages/system/kubevirt/templates/kubevirt-cr.yaml does not use it. The backup capability mentioned in the PR description will not be enabled after upgrade without additional manual configuration or helm value templating.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@packages/system/kubevirt-operator/templates/kubevirt-operator.yaml` around
lines 249 - 350, The packaged KubeVirt CR is missing the new
changedBlockTrackingLabelSelectors field, so changed-block-tracking (CBT) won't
be enabled after upgrade; update the packaged KubeVirt manifest's spec to
include changedBlockTrackingLabelSelectors and configure either
namespaceLabelSelector or virtualMachineLabelSelector to the desired scope
(e.g., matchLabels or matchExpressions that enable CBT for all VMs or specific
namespaces/VM labels). Locate the packaged KubeVirt CR manifest (the bundled
KubeVirt instance) and add a changedBlockTrackingLabelSelectors block matching
the schema (properties namespaceLabelSelector/virtualMachineLabelSelector with
matchLabels or matchExpressions) so CBT is enabled by default. Ensure the symbol
name changedBlockTrackingLabelSelectors exactly matches the schema added in the
CRD.
There was a problem hiding this comment.
Code Review
This pull request updates the KubeVirt operator from version 1.6.3 to 1.8.2, which includes significant updates to the operator manifest, CRD definitions, and RBAC permissions. Feedback indicates a potential regression in monitoring and alerting, as the ServiceMonitor and alert templates were deleted but their contents do not appear to be included in the updated main manifest. Additionally, an outdated comment in the Makefile regarding version 1.7.0 should be cleaned up to reflect the current status.
I am having trouble creating individual review comments. Click here to see my feedback.
packages/system/kubevirt-operator/templates/ServiceMonitor.yaml (1-13)
The PR description states that the ServiceMonitor and alerts were removed because they are now integrated into the main operator manifest. However, the updated kubevirt-operator.yaml does not contain any ServiceMonitor or PrometheusRule resources. Removing these files will likely break monitoring for the KubeVirt operator unless it now creates these resources dynamically at runtime. Please verify if the operator indeed manages its own ServiceMonitor or if these templates should be retained.
packages/system/kubevirt-operator/templates/alerts.yaml (1-7)
Similar to the ServiceMonitor, the alerts template and the corresponding alerts/ directory have been removed. If these alerts are not present in the new kubevirt-operator.yaml manifest (which they aren't), and the operator doesn't create them automatically, this will result in a loss of alerting capabilities.
packages/system/kubevirt-operator/Makefile (9)
The comment regarding v1.7.0 being blocked is likely outdated since the operator is being updated to v1.8.2. It should be removed or updated to reflect the current status.
Aleksei Sviridkin (lexfrei)
left a comment
There was a problem hiding this comment.
LGTM on the operator bump — vendored manifest is byte-identical to make update output for v1.8.2 and the new CRD fields (changed block tracking, hypervisor config, role aggregation) come through correctly.
One follow-up filed at #2503: the custom VMNotRunningFor10Minutes / VMINotRunningFor10Minutes alerts are silently dropped because templates/alerts.yaml (the glob loader for alerts/PrometheusRule.yaml) was removed but the data file is still on disk. Not a blocker for this PR — happy to land the upgrade and fix the loader separately.
Andrei Kvapil (kvaps)
left a comment
There was a problem hiding this comment.
When applying this update on the test cluster, all live-migrations that KubeVirt's workloadUpdateMethods automatically triggers fail with:
virError(Code=9, Domain=10, Message='operation failed: job 'migration in' failed:
load of migration failed: Operation not permitted')
qemu-kvm: error while loading state for instance 0x0 of device '0000:00:02.0:00.0/virtio-net'
This is a known KubeVirt issue: kubevirt/kubevirt#16386. When KubeVirt is upgraded across the QEMU bump (1.6.x → 1.7.x and beyond), VMs that were running before the upgrade have an in-memory device state that the new QEMU cannot reload, especially for virtio-net. Live-migration fails permanently for those VMs until they're cold-restarted.
The Makefile already references this issue (# v1.7.0 blocked by https://github.com/kubevirt/kubevirt/issues/16386), but jumping straight to v1.8.2 hits the same problem because the QEMU version difference vs. v1.6.3 is even larger.
Switching workloadUpdateMethods from [LiveMigrate, Evict] to [Evict] does not help — the eviction webhook intercepts evict requests and turns them back into live-migration (because the VMIs have evictionStrategy: LiveMigrate).
What's needed before merging:
- A documented procedure for handling existing running VMs during this upgrade (cold-restart workflow, evacuation plan, or similar), or
- An upstream fix / workaround for kubevirt#16386.
Holding merge until we agree on the path forward.
What this PR does
Updates KubeVirt operator from v1.6.3 to v1.8.2.
This update brings:
The standalone ServiceMonitor and alerts templates were removed as they are now integrated into the main operator manifest.
Screenshots
N/A - infrastructure component update
Release note
```release-note
chore(kubevirt-operator): update to v1.8.2
Updated KubeVirt operator from v1.6.3 to v1.8.2, adding support for changed block tracking and latest architectural improvements.
```
Summary by CodeRabbit
New Features
Chores