1
0
mirror of https://github.com/openshift/openshift-docs.git synced 2026-02-05 12:46:18 +01:00

Merge pull request #98094 from danielclowers/CNV-57754_01

CNV#57754_01: Misc 4.20 RN fixes
This commit is contained in:
Pan Ousley
2025-08-29 08:24:34 -04:00
committed by GitHub

View File

@@ -99,16 +99,6 @@ Deprecated features are included in the current release and supported. However,
* The `OperatorConditionsUnhealthy` alert is deprecated. You can safely xref:../../observability/monitoring/managing-alerts/managing-alerts-as-an-administrator.adoc#silencing-alerts-adm_managing-alerts-as-an-administrator[silence] it.
//CNV-63003 Release note: Deprecate feature gates
* The following `HyperConverged` custom resource (CR) fields have been deprecated and copied from their original location under the `spec.featureGates` fields to a new location in the `spec` field, where they can be used if needed:
** `DeployVmConsoleProxy`
** `EnableApplicationAwareQuota`
** `EnableCommonBootImageImport`
+
If used in the `spec.featureGates` location, the old fields are ignored.
[id="virt-4-20-removed_{context}"]
=== Removed features
@@ -131,9 +121,6 @@ link:https://access.redhat.com/support/offerings/techpreview[Technology Preview
// CNV-58423
* The `DevKubeVirtRelieveAndMigrate` descheduler profile is xref:../../virt/managing_vms/advanced_vm_management/virt-enabling-descheduler-evictions.adoc#nodes-descheduler-profiles_virt-enabling-descheduler-evictions[now available]. This profile enhances the `LongLifecycle` profile by supporting load-aware descheduling, dynamic soft taints, and improved workload rebalancing.
//CNV-62829
* You can now deploy {VirtProductName} on IPv6 single-stack clusters. Support for IPv6 single-stack is limited to the OVN-Kubernetes localnet and Linux bridge Container Network Interface (CNI) plugins.
[id="virt-4-20-bug-fixes_{context}"]
== Bug fixes
@@ -148,7 +135,8 @@ link:https://access.redhat.com/support/offerings/techpreview[Technology Preview
[discrete]
[id="virt-4-20-ki-networking_{context}"]
=== Networking
//CNV-38746
//CNV-38746: According to Petr, this will remain relevant as long as 4.12 is available. Anyone upgrading from 4.12 could be affected. Version 4.12 is supported until January 2026
* When you update from {product-title} 4.12 to a newer minor version, VMs that use the `cnv-bridge` Container Network Interface (CNI) fail to live migrate. (link:https://access.redhat.com/solutions/7069807[])
** As a workaround, change the `spec.config.type` field in your `NetworkAttachmentDefinition` manifest from `cnv-bridge` to `bridge` before performing the update.
@@ -156,7 +144,8 @@ link:https://access.redhat.com/support/offerings/techpreview[Technology Preview
[discrete]
[id="virt-4-20-ki-nodes_{context}"]
==== Nodes
//CNV-38543 - 4.16 Still an issue
//CNV-38543: According to Stu, this remains an issue in 4.20
* Uninstalling {VirtProductName} does not remove the `feature.node.kubevirt.io` node labels created by {VirtProductName}. You must remove the labels manually. (link:https://issues.redhat.com/browse/CNV-38543[*CNV-38543*])
[discrete]
@@ -182,7 +171,7 @@ include::snippets/technology-preview.adoc[]
//CNV-48348
* When the mode of live migration is *PostCopy*, hot-plugging CPU or memory resource fails. (link:https://issues.redhat.com/browse/CNV-48348[*CNV-48348*])
//CNV-33835: 4.16 - Unresolved
//CNV-33835: Per German, this was targeted for 4.20 but moved to 4.21 (see also CNV-27131)
* {VirtProductName} links a service account token in use by a pod to that specific pod. {VirtProductName} implements a service account volume by creating a disk image that contains a token. If you migrate a VM, then the service account volume becomes invalid. (link:https://issues.redhat.com/browse/CNV-33835[*CNV-33835*])
** As a workaround, use user accounts rather than service accounts because user account tokens are not bound to a specific pod.
@@ -221,5 +210,3 @@ You can also disable free page reporting of memory ballooning for all new VMs. T
// cnv-56890 - threads
* In the {product-title} web console, it is erroneously possible to define multiple CPU threads for a VM based on s390x architecture. If you define multiple CPU threads, the VM enters a `CrashLoopBackOff` state with the `qemu-kvm: S390 does not support more than 1 threads` error. (link:https://issues.redhat.com/browse/CNV-56890[CNV-56890])