Beta Features Enabled by Default in KubeVirt v1.9 | KubeVirt.io

Starting from KubeVirt v1.9, all Beta feature gates are enabled by default. This is a significant behavioral change from previous versions, where Beta features had to be explicitly opted into. If you are a downstream vendor, cluster administrator, or anyone deploying KubeVirt in production, please read on to understand what this means and how to prepare.
The Beta phase of a feature is a “dress rehearsal” before General Availability (GA). During this phase, the community needs to ensure the feature is stable, gather wide user feedback, and validate that the API remains solid.
Previously, Beta features were off by default. This meant they were often under-tested in real environments, limiting the community’s ability to catch issues early. By enabling Beta features by default, we:
This change was proposed and discussed publicly in VEP 229 and implemented in PR #17405.
All Beta feature gates were disabled by default. To use a Beta feature, you had to explicitly add it to spec.configuration.developerConfiguration.featureGates in the KubeVirt CR:
All Beta feature gates are enabled by default. To disable a Beta feature you do not want, add it to spec.configuration.developerConfiguration.disabledFeatureGates:
Note that Alpha features remain off by default and must still be explicitly enabled via featureGates.
To help downstream vendors and cluster administrators understand which features are active and at what maturity level, starting from v1.9, KubeVirt ships a feature gate report as part of every release’s artifacts.
This is a JSON file listing every non-GA feature gate and its current state (Alpha, Beta, or Deprecated). You can find it in the release artifacts for each version.
You can also generate the report yourself from any KubeVirt source tree by running:
At the time of writing, the feature gate report looks as follows (the actual report shipped with the v1.9 release artifacts may differ):
Using this report, you can easily identify all Beta features that will now be on by default and decide which, if any, you want to disable.
If you are upgrading from v1.8, the disabledFeatureGates mechanism is already available to you. Before upgrading, review the feature gate report and add any Beta features you want to keep disabled to disabledFeatureGates in your KubeVirt CR.
The disabledFeatureGates field was introduced in v1.8. If you are skipping v1.8 and upgrading directly from v1.7 to v1.9, be aware that:
If you ship a product based on KubeVirt, this change directly affects your release pipeline. Here are specific recommendations:
Use disabledFeatureGates in your KubeVirt CR to disable features that are not ready for your product:
As recommended above, use the feature gate report JSON from the release artifacts to programmatically extract all Beta features and disable them in your KubeVirt CR.
HCO (Hyperconverged Cluster Operator) will explicitly manage which Beta features are enabled or disabled. HCO maintainers will use the feature gate report to decide on defaults, with an in-code exception list for features they choose to configure differently.
If HCO’s defaults do not match your needs, you can override the KubeVirt CR’s disabledFeatureGates list using JSON patches.
This change helps the community deliver more stable features at GA. If you have questions, please reach out on the kubevirt-dev mailing list or join the #kubevirt-dev channel on Kubernetes Slack.
For full details, see VEP 229.
We are a Cloud Native Computing Foundation incubating project.