Merge pull request #27271 from sjhala-ccs/cnv-2-5-rn

OpenShift Virtualization 2.5 release notes

Author: aburdenthehand

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

@@ -7,25 +7,33 @@ 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.
+Red Hat {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},40,40] 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:
+
+Learn more about xref:../virt/about-virt.adoc#about-virt[what you can do with {VirtProductName}].
 
 include::modules/virt-supported-cluster-version.adoc[leveloffset=+2]
 
+//CNV-4572-Guest-OS
+[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-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:
@@ -34,10 +42,7 @@ The SVVP Certification applies to:
 
 ** Intel and AMD CPUs.
 
-//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
-
 * {VirtProductName} {VirtVersion} adds three new xref:../virt/virt-using-the-cli-tools.adoc#virt-virtctl-commands_virt-using-the-cli-tools[`virtctl` commands] to manage QEMU guest agent data:
 
 ** `virtctl fslist <vmi_name>` returns a full list of file systems available on the guest machine.
@@ -47,17 +52,6 @@ The SVVP Certification applies to:
 //CNV-7295 - Download virtctl binary from the CLI Tools page
 * You can now download the `virtctl` client from the xref:../virt/install/virt-installing-virtctl.adoc#virt-installing-virtctl-client-web_virt-installing-virtctl[*Command Line Tools* page in the web console].
 
-//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.
@@ -70,13 +64,13 @@ Other operating system templates shipped with {VirtProductName} are not supporte
 //Placeholder for new content.
 
 //CNV-7170 - CDI import of container disks is faster and more efficient
-* The Containerized Data Importer (CDI) can now import containerDisk storage volumes from the container image registry at a faster speed and allocate storage capacity more efficiently. CDI can pull a containerDisk image from the registry in about the same amount of time as it would take to import from an HTTP endpoint. You can import the disk into a PersistentVolumeClaim (PVC) equal in size to the disk image to use the underlying storage more efficiently.
+* The Containerized Data Importer (CDI) can now xref:../virt/virtual_machines/virtual_disks/virt-using-container-disks-with-vms.adoc#virt-using-container-disks-with-vms[import container disk storage volumes] from the container image registry at a faster speed and allocate storage capacity more efficiently. CDI can pull a container disk image from the registry in about the same amount of time as it would take to import from an HTTP endpoint. You can import the disk into a persistent volume claim (PVC) equal in size to the disk image to use the underlying storage more efficiently.
 
 //CNV-7168 - DataVolume and storage diagnostics
-* It is now easier to diagnose and troubleshoot issues when preparing virtual machine (VM) disks that are managed by DataVolumes:
+* It is now easier to xref:../virt/logging_events_monitoring/virt-diagnosing-datavolumes-using-events-and-conditions.adoc#virt-diagnosing-datavolumes-using-events-and-conditions[diagnose and troubleshoot issues] when preparing virtual machine (VM) disks that are managed by DataVolumes:
 +
 ** For asynchronous image upload, if the virtual size of the disk image is larger than the size of the target DataVolume, an error message is returned before the connection is closed.
-** You can use the `oc describe dv` command to monitor changes in the PersistentVolumeClaim (PVC) `Bound` conditions or transfer failures. If the value of the `Status:Phase` field is `Succeeded`, then the DataVolume is ready to be used.
+** You can use the `oc describe dv` command to monitor changes in the `PersistentVolumeClaim` (PVC) `Bound` conditions or transfer failures. If the value of the `Status:Phase` field is `Succeeded`, then the DataVolume is ready to be used.
 
 //CNV-6824 - Offline virtual machine snapshots
 * You can create, restore, and delete virtual machine (VM) snapshots in the CLI for VMs that are powered off (offline). {VirtProductName} supports
@@ -88,7 +82,7 @@ xref:../virt/virtual_machines/virtual_disks/virt-managing-offline-vm-snapshots.a
 //CNV-6825 - Smart cloning with snapshots
 //CNV-4089 - Cloning a disk quickly using the storage array
 // These two release note stories are combined in a single release note.
-* You can now clone virtual disks efficiently and quickly using smart-cloning. Smart-cloning occurs automatically when you create a DataVolume with a PersistentVolumeClaim (PVC) source. Your storage provider must support the CSI Snapshots API to use smart-cloning.
+* You can now clone virtual disks efficiently and quickly using xref:../virt/virtual_machines/virtual_disks/virt-cloning-a-datavolume-using-smart-cloning#virt-cloning-a-datavolume-using-smart-cloning[smart-cloning]. Smart-cloning occurs automatically when you create a DataVolume with a `PersistentVolumeClaim` (PVC) source. Your storage provider must support the CSI Snapshots API to use smart-cloning.
 
 [id="virt-2-5-web-new"]
 === Web console
@@ -108,13 +102,13 @@ The *Pending Changes* banner at the top of the page displays a list of all chang
 * You can now xref:../virt/virtual_machines/virt-accessing-vm-consoles.adoc#virt-vm-serial-console-web_virt-accessing-vm-consoles[open a virtual machine console] in a separate window.
 
 //CNV-7169 - Auto-clone base images when creating VM in UI
-* You can now create default OS images and automatically upload them using the {product-title} web console. A _default OS image_ is a bootable disk containing an operating system and all of the operating system's configuration settings, such as drivers. You use a default OS image to create bootable virtual machines with specific configurations.
+* You can now xref:../virt/virtual_machines/virtual_disks/virt-creating-and-using-default-os-images#virt-creating-and-using-default-os-images[create default OS images] and automatically upload them using the {product-title} web console. A _default OS image_ is a bootable disk containing an operating system and all of the operating system's configuration settings, such as drivers. You use a default OS image to create bootable virtual machines with specific configurations.
 
 //CNV-7314 - Expose VM image upload in UI
 * You can now xref:../virt/virtual_machines/virtual_disks/virt-uploading-local-disk-images-web.adoc#virt-uploading-local-disk-images-web[upload a virtual machine image file] to a new persistent volume claim by using the web console.
 
 //CNV-7317 - Expose qemu guest agent data in the UI
-* When the QEMU guest agent runs on the virtual machine, you can use the web console to view information about the virtual machine, users, file systems, and secondary networks.
+* When the QEMU guest agent runs on the virtual machine, you can use the web console to xref:../virt/virtual_machines/virt-viewing-qemu-guest-agent-web#virt-viewing-qemu-guest-agent-web[view information] about the virtual machine, users, file systems, and secondary networks.
 
 [id="virt-2-5-changes"]
 == Notable technical changes
@@ -145,9 +139,10 @@ The *Pending Changes* banner at the top of the page displays a list of all chang
 
 //This section is work in progress
 
-* When a node fails in user-provisioned installations of {product-title} on bare metal deployments, the virtual machine does not automatically restart on another node. Automatic restart is supported only for installer-provisioned installations that have machine health checks enabled. (link:https://bugzilla.redhat.com/show_bug.cgi?id=1886437[*BZ#1886437*])
+//CNV-7548
+* When a node fails in user-provisioned installations of {product-title} on bare metal deployments, the virtual machine does not automatically restart on another node. Automatic restart is supported only for installer-provisioned installations that have machine health checks enabled. Learn more about xref:/../virt/install/preparing-cluster-for-virt#preparing-cluster-for-virt[configuring your cluster for {VirtProductName}].
 
-* If your {product-title} cluster uses OVN-Kubernetes as the default Container Network Interface (CNI) provider, you cannot attach a Linux bridge or bonding to the default interface of a host because of a change in the host network topology of OVN-Kubernetes. As a workaround, you can use a secondary network interface connected to your host or switch to the OpenShift SDN default CNI provider. link:https://bugzilla.redhat.com/show_bug.cgi?id=1887456[(*BZ#1887456*)]
+* If your {product-title} cluster uses OVN-Kubernetes as the default Container Network Interface (CNI) provider, you cannot attach a Linux bridge or bonding to the default interface of a host because of a change in the host network topology of OVN-Kubernetes. As a workaround, you can use a secondary network interface connected to your host or switch to the OpenShift SDN default CNI provider. (link:https://bugzilla.redhat.com/show_bug.cgi?id=1887456[*BZ#1887456*])
 
 //This defect is on Verified status but the fix is not ideal. This known issue is likely to be removed for 2.6.
 * If you xref:../virt/virtual_machines/importing_vms/virt-importing-vmware-vm.adoc#virt-creating-vddk-image_virt-importing-vmware-vm[add a VMware Virtual Disk Development Kit (VDDK) image] to the `openshift-cnv/v2v-vmware` config map by using the web console, a *Managed resource* error message displays. You can safely ignore this error. Save the config map by clicking *Save*. (link:https://bugzilla.redhat.com/show_bug.cgi?id=1884538[*BZ#1884538*])
@@ -159,7 +154,7 @@ The *Pending Changes* banner at the top of the page displays a list of all chang
 //This defect is on Verified status
 * 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
+//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
@@ -174,9 +169,7 @@ As a workaround, you can reconfigure the virtual machines so that they can be po
 * 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*])
+* 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:
 +
@@ -187,19 +180,14 @@ $ export TARGET_NAMESPACE=openshift-cnv CNV_CHANNEL=2.5 && oc patch -n "${TARGET
 +
 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*])
+//This defect is on POST status
+* 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.
+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:
@@ -219,34 +207,22 @@ metadata:
 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.
+<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.
+* {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].
 
 //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*])
+//Unresolved
+* 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=1887140[*BZ#1887140*])
 +
 To unlock the account, log in to the Manager and enter the following command:
 +
 [source,terminal]
 ----
 $ ovirt-aaa-jdbc-tool user unlock admin
 ----
-
-//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*])