diff --git a/modules/virt-supported-cluster-version.adoc b/modules/virt-supported-cluster-version.adoc new file mode 100644 index 000000000000..8075c668bde2 --- /dev/null +++ b/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. + diff --git a/virt/virt-2-5-release-notes.adoc b/virt/virt-2-5-release-notes.adoc new file mode 100644 index 000000000000..849c7638640b --- /dev/null +++ b/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: "" <1> +---- +<1> Replace `` with the actual CPU model value. You can determine this +value by running `oc describe node ` for all nodes and looking at the +`cpu-model-` 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*)]