RN-OpenShift Virtualization 2.5 Release Notes

modules/virt-supported-cluster-version.adoc

@@ -0,0 +1,10 @@
+// Module included in the following assemblies:
+//
+// * virt/about-virt.adoc
+// * virt/virt_release_notes/virt-2-4-release-notes.adoc
+
+[id="virt-supported-cluster-version_{context}"]
+= {VirtProductName} supported cluster version
+
+{VirtProductName} {VirtVersion} is supported for use on {product-title} {product-version} clusters.
+

virt/virt-2-5-release-notes.adoc

@@ -0,0 +1,204 @@
+[id="virt-2-5-release-notes"]
+= {RN_BookName}
+include::modules/virt-document-attributes.adoc[]
+:context: virt-release-notes
+toc::[]
+
+== About Red Hat {VirtProductName}
+
+Red Hat {VirtProductName} {VirtVersion} is supported for use on {product-title} 4.6 clusters. {VirtProductName} enables you to bring traditional virtual machines (VMs) into {product-title} where they run alongside containers, and are managed as native Kubernetes objects.
+
+//Branding-Logo
+{VirtProductName} is represented by the image:Operator_Icon-OpenShift_Virtualization-5.png[{VirtProductName}] logo.
+
+include::modules/virt-what-you-can-do-with-virt.adoc[leveloffset=+2]
+// This line is attached to the above `virt-what-you-can-do-with-virt` module.
+// It is included here in the assembly because of the xref ban.
+You can use {VirtProductName} with either the xref:../networking/ovn_kubernetes_network_provider/about-ovn-kubernetes.adoc#about-ovn-kubernetes[OVN-Kubernetes] or the xref:../networking/openshift_sdn/about-openshift-sdn.adoc#about-openshift-sdn[OpenShiftSDN] default Container Network Interface (CNI) network provider.
+//Commented out because for GA release we have special text that covers this info. But going forward, we will want to include the following:
+include::modules/virt-supported-cluster-version.adoc[leveloffset=+2]
+
+[id="virt-2-5-new"]
+== New and changed features
+//Placeholder for new content.
+
+//CNV-4904 Microsoft's SVVP certification applies to RHCOS workers. The content below from the 2.4 release notes seems to cover this already.
+
+* {VirtProductName} is certified in Microsoft's Windows Server Virtualization Validation Program (SVVP) to run Windows Server workloads.
++
+The SVVP Certification applies to:
+
+** Red Hat Enterprise Linux CoreOS 8 workers. In the Microsoft SVVP Catalog, they are named _Red Hat {product-title} 4 on RHEL CoreOS 8_.
+
+** Intel and AMD CPUs.
+
+//CNV-7293 - Use OLM stable channel for installation
+
+//CNV-7294 - Cluster admin can now influence node placement using new API on HCO CR
+
+//CNV-7160 - New virtctl commands to expose raw qemu guest agent data
+
+//CNV-7295 - Download virtctl binary from the CLI Tools page
+
+
+//CNV-4572-Guest-OS Should we still keep this info from the 2.4 release notes?
+[id="virt-guest-os-new"]
+=== Supported guest operating systems
+{VirtProductName} guests can use the following operating systems:
+
+* Red Hat Enterprise Linux 6, 7, and 8.
+* Microsoft Windows Server 2012 R2, 2016, and 2019.
+* Microsoft Windows 10.
+
+Other operating system templates shipped with {VirtProductName} are not supported.
+
+[id="virt-2-5-networking-new"]
+=== Networking
+//Placeholder for new content.
+
+//CNV-5263 - Supported bonding modes with nmstate
+
+[id="virt-2-5-storage-new"]
+=== Storage
+//Placeholder for new content.
+
+//CNV-7170 - CDI import of container disks is faster and more efficient
+
+//CNV-7168 - DataVolume and storage diagnostics
+
+//CNV-6824 - Offline virtual machine snapshots
+
+//CNV-6825 - Smart cloning with snapshots
+
+//CNV-4089 - Cloning a disk quickly using the storage array
+
+[id="virt-2-5-web-new"]
+=== Web console
+//Placeholder for new content.
+
+//CNV-7315 - Expose next run configuration in the UI
+
+//CNV-7318 - Open the vnc/serial console in a new window
+
+//CNV-7169 - Auto-clone base images when creating VM in UI
+
+//CNV-7314 - Expose VM image upload in UI
+
+//CNV-7317 - Expose qemu guest agent data in the UI
+
+[id="virt-2-5-changes"]
+== Notable technical changes
+//Placeholder for new content.
+
+//CNV-7293 - Use OLM stable channel for installation
+
+//CNV-7102 - Block based storage support using vm-import-controller
+
+//CNV-7296 - HCO and HPP CRs moved to v1beta1
+
+
+[id="virt-2-5-known-issues"]
+== Known issues
+
+//This section is work in progress
+
+//This defect is ON_QA
+* If you enable a MAC address pool for a namespace by applying the KubeMacPool label and using the `io` attribute for virtual machines in that namespace, the `io` attribute configuration is not retained for the VMs. As a workaround, do not use the `io` attribute for VMs. Alternatively, you can disable KubeMacPool for the namespace. (link:https://bugzilla.redhat.com/show_bug.cgi?id=1869527[*BZ#1869527*])
+
+//This defect is still unresolved, moved to 2.6
+* If you upgrade to {VirtProductName} {VirtVersion}, both older and newer versions of common templates are available for each combination of operating system, workload, and flavor. When you create a virtual machine by using a common template, you must use the newer version of the template. Disregard the older version to avoid issues. (link:https://bugzilla.redhat.com/show_bug.cgi?id=1859235[*BZ#1859235*])
+
+//Unresolved
+* Running virtual machines that cannot be live migrated might block an {product-title} cluster upgrade. This includes virtual machines that use hostpath-provisioner storage or SR-IOV network interfaces.(link:https://bugzilla.redhat.com/show_bug.cgi?id=1858777[*BZ#1858777*])
+
+As a workaround, you can reconfigure the virtual machines so that they can be powered off during a cluster upgrade. In the `spec` section of the virtual machine configuration file:
++
+** Remove the `evictionStrategy: LiveMigrate` field. See xref:../virt/live_migration/virt-configuring-vmi-eviction-strategy.adoc#virt-configuring-vmi-eviction-strategy[Configuring virtual machine eviction strategy] for more information on how to configure eviction strategy.
+** Set the `runStrategy` field to `Always`.
+
+//Unresolved, on ASSIGNED status
+* For unknown reasons, memory consumption for the `containerDisk` volume type might gradually increase until it exceeds the memory limit. To resolve this issue, restart the VM. (link:https://bugzilla.redhat.com/show_bug.cgi?id=1855067[*BZ#1855067*])
+
+//Unresolved, on ASSIGNED status
+* Sometimes, when attempting to edit the subscription channel of the *{VirtProductName} Operator* in the web console, clicking the
+*Channel* button of the *Subscription Overview* results in a JavaScript error.
+(link:https://bugzilla.redhat.com/show_bug.cgi?id=1796410[*BZ#1796410*])
+
+** As a workaround, trigger the upgrade process to {VirtProductName} {VirtVersion}
+from the CLI by running the following `oc` patch command:
++
+----
+$ export TARGET_NAMESPACE=openshift-cnv CNV_CHANNEL=2.5 && oc patch -n "${TARGET_NAMESPACE}" $(oc get subscription -n ${TARGET_NAMESPACE} --no-headers -o name) --type='json' -p='[{"op": "replace", "path": "/spec/channel", "value":"'${CNV_CHANNEL}'"}, {"op": "replace", "path": "/spec/installPlanApproval", "value":"Automatic"}]'
+----
++
+This command points your subscription to upgrade channel `2.5` and enables automatic updates.
+
+//This defect is in POST status [*BZ#1760028*]
+* Live migration fails when nodes have different CPU models. Even in cases where
+nodes have the same physical CPU model, differences introduced by microcode
+updates have the same effect. This is because the default settings trigger
+host CPU passthrough behavior, which is incompatible with live migration.
+(link:https://bugzilla.redhat.com/show_bug.cgi?id=1760028[*BZ#1760028*])
++
+** As a workaround, set the default CPU model in the `kubevirt-config` ConfigMap,
+as shown in the following example:
++
+[NOTE]
+====
+You must make this change before starting the virtual machines that support
+live migration.
+====
++
+. Open the `kubevirt-config` ConfigMap for editing by running the following command:
++
+----
+$ oc edit configmap kubevirt-config -n openshift-cnv
+----
++
+. Edit the ConfigMap:
++
+[source,yaml]
+----
+kind: ConfigMap
+metadata:
+  name: kubevirt-config
+data:
+  default-cpu-model: "<cpu-model>" <1>
+----
+<1> Replace `<cpu-model>` with the actual CPU model value. You can determine this
+value by running `oc describe node <node>` for all nodes and looking at the
+`cpu-model-<name>` labels. Select the CPU model that is present on all of your
+nodes.
+
+//Jira story for the following content https://issues.redhat.com/browse/CNV-4757.
+* {VirtProductName} cannot reliably identify node drains that are triggered by
+running either `oc adm drain` or `kubectl drain`. Do not run these commands on
+the nodes of any clusters where {VirtProductName} is deployed. The nodes might not
+drain if there are virtual machines running on top of them.
+
+** The current solution is to xref:../virt/node_maintenance/virt-setting-node-maintenance.adoc#virt-setting-node-maintenance[put nodes into maintenance].
+
+//Cannot locate defect in BZ
+* You must create a custom ConfigMap in order to import a Red Hat Virtualization (RHV) VM into {VirtProductName}.
+
+//This defect is on Verified status
+* If the {VirtProductName} storage PV is not suitable for importing a RHV VM, the progress bar remains at 10% and the import does not complete. The VM Import Controller Pod log displays the following error message: `Failed to bind volumes: provisioning failed for PVC`. link:https://bugzilla.redhat.com/show_bug.cgi?id=1857784[(*BZ#1857784*)]
+
+//This defect is ON_QA
+* If you enter the wrong credentials for the RHV Manager while importing a RHV VM, the Manager might lock the admin user account because the `vm-import-operator` tries repeatedly to connect to the RHV API. link:https://bugzilla.redhat.com/show_bug.cgi?id=1854425[*BZ#1854425*]
+
+To unlock the account, log in to the Manager and enter the following command:
++
+[source,terminal]
+----
+$ ovirt-aaa-jdbc-tool user unlock admin
+----
+
+//Cannot locate defect in BZ
+* If a RHV VM disk is in a `Locked` state, you must link:https://access.redhat.com/solutions/396753[unlock the disk] before you can import it.
+
+//This defect is on Verified status
+* `cloud-init` settings are not imported with a RHV virtual machine. You must recreate `cloud-init` after the import process.link:https://bugzilla.redhat.com/show_bug.cgi?id=1850574[*BZ#1850574]
+
+// This defect is ON_QA
+* {VirtProductName} does not support UEFI. If you import a VMware VM with UEFI BIOS into OpenShift Virtualization, the VM will not boot. link:https://bugzilla.redhat.com/show_bug.cgi?id=1880083[(*BZ#1880083*)]