1
0
mirror of https://github.com/openshift/openshift-docs.git synced 2026-02-05 12:46:18 +01:00
Files
openshift-docs/virt/virt-4-9-release-notes.adoc
2025-04-16 10:10:08 -04:00

207 lines
13 KiB
Plaintext
Raw Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
:_mod-docs-content-type: ASSEMBLY
[id="virt-4-9-release-notes"]
= {VirtProductName} release notes
include::_attributes/common-attributes.adoc[]
:context: virt-4-9-release-notes
toc::[]
== About Red Hat {VirtProductName}
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.
{VirtProductName} is represented by the image:Operator_Icon-OpenShift_Virtualization-5.png[{VirtProductName},40,40] logo.
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.
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]
[id="virt-guest-os"]
=== Supported guest operating systems
{VirtProductName} guests can use the following operating systems:
* Red Hat Enterprise Linux 6, 7, and 8.
* Red Hat Enterprise Linux 9 Alpha (Technology Preview).
* Microsoft Windows Server 2012 R2, 2016, and 2019.
* Microsoft Windows 10.
Other operating system templates shipped with {VirtProductName} are not supported.
//CNV-8167 Supported guest operating systems
//CNV-13793 Supported guest OS
[id="virt-4-9-new"]
== New and changed features
//CNV-8875 OLM and stable channels
//CNV-8577 OpenShift Service Mesh: Commenting out the RN because the feature will now be available in 4.10
////
* {VirtProductName} is now integrated with OpenShift Service Mesh. You can xref:../virt/virtual_machines/vm_networking/virt-connecting-vm-to-service-mesh.adoc#virt-connecting-vm-to-service-mesh[connect virtual machines to a service mesh] to monitor, visualize, and control traffic between pods that run virtual machine workloads on the default pod network with IPv4.
////
//CNV-12858
* {VirtProductName} is certified in Microsofts Windows Server Virtualization Validation Program (SVVP) to run Windows Server workloads.
+
The SVVP Certification applies to:
+
** Red Hat Enterprise Linux CoreOS workers. In the Microsoft SVVP Catalog, they are named __Red Hat OpenShift Container Platform 4 on RHEL CoreOS__.
** Intel and AMD CPUs.
//CNV-9540 High performance windows
* High-performance virtual machine templates are now available for xref:virt-guest-os[supported Windows operating systems].
//CNV-8875
* If your {VirtProductName} Operator subscription used any update channel other than *stable*, it is now automatically subscribed to the *stable* channel. This single update channel delivers z-stream and minor version updates and ensures that your {VirtProductName} and {product-title} versions are compatible.
//CNV-14246
* You can now use the `virtctl guestfs` command xref:../virt/virt-using-the-cli-tools.html#virt-creating-pvc-with-virtctl-guestfs_virt-using-the-cli-tools[to maintain, repair, and debug virtual machine disks].
//CNV-14262
* You can now xref:../virt/virtual_machines/advanced_vm_management/virt-efi-mode-for-vms.html#virt-booting-vms-efi-mode_virt-efi-mode-for-vms[boot virtual machines with EFI mode] without mandatory Secure Boot.
[id="virt-4-9-quick-starts"]
=== Quick starts
* Quick start tours are available for several {VirtProductName} features. To view the tours, click the *Help* icon *?* in the menu bar on the header of the {VirtProductName} console and then select *Quick Starts*. You can filter the available tours by entering the `virtualization` keyword in the *Filter* field.
[id="virt-4-9-installation-new"]
=== Installation
//CNV-14191 FIPS on CNV
* You can now deploy {VirtProductName} on xref:../installing/installing-fips.adoc#installing-fips[FIPS-enabled clusters].
* You can now download the xref:../virt/install/virt-enabling-virtctl.adoc#virt-enabling-virtctl[`virtctl` client] even if the cluster is offline by using the `ConsoleCLIDownload` custom resource (CR).
[id="virt-4-9-networking-new"]
=== Networking
//CNV-11197 MAC spoof filtering
* You can now xref:../virt/virtual_machines/vm_networking/virt-attaching-vm-multiple-networks.adoc#virt-creating-bridge-nad-cli_virt-attaching-multiple-networks[enable or disable MAC spoof filtering] on secondary networks by configuring a Linux bridge network attachment definition in the CLI.
[id="virt-4-9-storage-new"]
=== Storage
//CNV-14247 CSI Clones
* You can use storage profiles to set a default cloning method for a storage class, creating a xref:../virt/virtual_machines/virtual_disks/virt-creating-data-volumes.adoc#virt-customizing-storage-profile-default-cloning-strategy_virt-creating-data-volumes[cloning strategy]. Setting cloning strategies can be helpful, for example, if your storage vendor only supports certain cloning methods. It also allows you to select a method that limits resource usage or maximizes performance. In addition to previously available cloning methods such as snapshots and host-assisted cloning, you can now specify `csi-clone` as the default cloning behavior, which uses the CSI clone API to efficiently clone an existing volume without using an interim volume snapshot.
//CNV-14245 Online VM snapshots
* You can now take a xref:../virt/virtual_machines/virtual_disks/virt-managing-vm-snapshots.adoc#virt-about-vm-snapshots_virt-managing-vm-snapshots[snapshot of an online virtual machine]. If the QEMU guest agent is installed, the file system is quiesced when taking the snapshot, maximizing data integrity.
[id="virt-4-9-web-new"]
=== Web console
//BZ-1931579 Virt machine template descriptions
//CNV-14219 Sysprep UI
* You can now xref:../virt/virtual_machines/virt-create-vms.adoc#virt-creating-vm-wizard-web_virt-create-vms[automate your Windows virtual machine setup] by uploading answer files in XML format in the *Advanced* -> *SysPrep* section of the *Create virtual machine from template* wizard.
//CNV-11664 Rhel 9 OCP Virt
//CNV-14193 Virt dashboard
* You can use the xref:../virt/logging_events_monitoring/virt-reviewing-vm-dashboard.adoc#virt-reviewing-vm-dashboard[{VirtProductName} dashboard] in the web console to get data on resource consumption for virtual machines and associated pods. The dashboard provides visual representations of cluster metrics so you can quickly understand the state of your cluster.
// NOTE: no deprecated features in 4.9; commenting out these sections to retain for future use
//[id="virt-4-9-deprecated-removed"]
//== Deprecated and removed features
//[id="virt-4-9-deprecated"]
//=== Deprecated features
//Deprecated features are included in the current release and supported. However, they will be removed in a future release and are not recommended for new deployments.
// NOTE: when uncommenting deprecated features list, change the header level below to ===
[id="virt-4-9-removed"]
== Removed features
Removed features are not supported in the current release.
* Importing a single virtual machine from Red Hat Virtualization (RHV) or VMware is removed from {VirtProductName} 4.9. This feature is replaced by the link:https://access.redhat.com/documentation/en-us/migration_toolkit_for_virtualization[Migration Toolkit for Virtualization].
// NOTE: no notable technical changes in 4.9, commenting out to retain
//[id="virt-4-9-changes"]
//== Notable technical changes
[id="virt-4-9-technology-preview"]
== Technology Preview features
Some features in this release are currently in Technology Preview. These experimental features are not intended for production use. Note the following scope of support on the Red Hat Customer Portal for these features:
link:https://access.redhat.com/support/offerings/techpreview[Technology Preview Features Support Scope]
//CNV-14192 virt-launcher now automatically updates - now TP
* You can now enable automatic updates for {VirtProductName} workloads, such as `virt-launcher` pods. xref:../virt/upgrading-virt.adoc#configuring-workload-updates_upgrading-virt[Configure workload update strategies] by editing the `HyperConverged` custom resource.
* You can now xref:../virt/virtual_machines/virtual_disks/virt-hot-plugging-virtual-disks.adoc#virt-hot-plugging-virtual-disks[hot-plug and hot-unplug virtual disks] when you want to add or remove them from your virtual machine without stopping the virtual machine instance.
* You can now use the Red Hat Enterprise Linux 9 Alpha template to create virtual machines.
[id="virt-4-9-known-issues"]
== Known issues
//New known issues should go below here.
//BZ-1963254 UEFI without Secure Boot
//BZ-2007397
* If you hot-plug a virtual disk and then force delete the `virt-launcher` pod, you might lose data. This is due to a race condition that can cause the VM disk's contents to be wiped from the persistent volume. (link:https://bugzilla.redhat.com/show_bug.cgi?id=2007397[*BZ#2007397*])
//New known issues should go above here.
* If a cloning operation is initiated before the source is available to be cloned, the operation stalls indefinitely. This is because the clone authorization expires before the cloning operation starts. (link:https://bugzilla.redhat.com/show_bug.cgi?id=1855182[*BZ#1855182*])
+
** As a workaround, delete the `DataVolume` object that is requesting the clone. When the source is available, recreate the `DataVolume` object that you deleted so that the cloning operation can complete successfully.
* 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. (link:https://bugzilla.redhat.com/show_bug.cgi?id=1885605[*BZ#1885605*])
** As a workaround, you can use a secondary network interface connected to your host, or switch to the OpenShift SDN default CNI provider.
* 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`.
* 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 by running the following command:
+
[NOTE]
====
You must make this change before starting the virtual machines that support live migration.
====
+
[source,terminal]
----
$ oc annotate --overwrite -n openshift-cnv hyperconverged kubevirt-hyperconverged kubevirt.kubevirt.io/jsonpatch='[
{
"op": "add",
"path": "/spec/configuration/cpuModel",
"value": "<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.
* 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
----
// fix targeted for 4.8.1
* RHV VM import fails if the VM affinity policy is `Migratable` even when live migration is enabled in {VirtProductName}. VM import succeeds if the affinity policy is `Pinned`. (link:https://bugzilla.redhat.com/show_bug.cgi?id=1977277[*BZ#1977277*])
// fix targeted for 4.8.1
* Selecting *Create* -> *With Import wizard* on the *Virtualization* page of the {VirtProductName} console displays the following warning message:
+
[source]
----
Could not load VirtualMachines
No model registered for VirtualMachines
----
+
You can ignore this message. It does not affect VM import. (link:https://bugzilla.redhat.com/show_bug.cgi?id=1974812[*BZ#1974812*])