diff --git a/virt/release_notes/virt-4-20-release-notes.adoc b/virt/release_notes/virt-4-20-release-notes.adoc index 8f1f8f192b..abfb59900f 100644 --- a/virt/release_notes/virt-4-20-release-notes.adoc +++ b/virt/release_notes/virt-4-20-release-notes.adoc @@ -137,6 +137,19 @@ link:https://access.redhat.com/support/offerings/techpreview[Technology Preview [id="virt-4-20-bug-fixes_{context}"] == Bug fixes +// CNV-61279 +* Restoring a snapshot of a VM after a storage migration no longer fails because of unreferenced `dataVolumeTemplate` objects. The snapshot process now refreshes the data volume templates in the controller revision to match the `volumes` list, ensuring consistent data recovery. (link:https://issues.redhat.com/browse/CNV-61279[*CNV-61279*]) + +// CNV-48348 +* The migration controller in the `virt-handler` pod was redesigned to separate source, target, and VM responsibilities, ensure deterministic completion, and use a unified `VirtualMachineInstance` (VMI) cache. (link:https://issues.redhat.com/browse/CNV-48348[*CNV-48348*]) + +// CNV-36448 +* Virtual Trusted Platform Module (vTPM) persistence is now enabled by default in VM templates. BitLocker system checks in Windows VMs no longer pass with non-persistent vTPM devices. (link:https://issues.redhat.com/browse/CNV-36448[*CNV-36448*]) + +// CNV-61740 +* On s390x systems, VMs created from a template with the *Boot from CD* option now boot correctly. CD-ROM devices are attached as SCSI instead of SATA, which is not supported on s390x architecture. (link:https://issues.redhat.com/browse/CNV-61740[*CNV-61740*]) + + [id="virt-4-20-known-issues_{context}"] == Known issues @@ -165,32 +178,14 @@ link:https://access.redhat.com/support/offerings/techpreview[Technology Preview [id="virt-4-20-ki-storage_{context}"] ==== Storage -//CNV-61279: 4.19 - Storage Migrate VM with MTC -* Restoring a snapshot of a virtual machine (VM) migrated using Migration Toolkit for Containers (MTC) fails. The restore creates a persistent volume claim (PVC) but not a data volume (DV). The VM spec references a `DataVolumeTemplate` missing from the `volumes` list. (link:https://issues.redhat.com/browse/CNV-61279[*CNV-61279*]) -** As a workaround, restart the VM after storage migration and before taking the snapshot. This creates a new controller revision that avoids the issue. - -// CNV-55104: 4.18 - Unresolved -* If you perform storage class migration for a stopped VM, the VM might not be able to start because of a missing bootable device. To prevent this, do not attempt storage class migration if the VM is not running. (link:https://issues.redhat.com/browse/CNV-55104[*CNV-55104*]) -+ --- -:FeatureName: Storage class migration -include::snippets/technology-preview.adoc[] --- - [discrete] [id="virt-4-20-ki-virtualization_{context}"] === Virtualization -//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: 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. -//CNV-36448 -* When adding a virtual Trusted Platform Module (vTPM) device to a Windows VM, the BitLocker Drive Encryption system check passes even if the vTPM device is not persistent. This is because a vTPM device that is not persistent stores and recovers encryption keys using ephemeral storage for the lifetime of the virt-launcher pod. When the VM migrates or is shut down and restarts, the vTPM data is lost. (link:https://issues.redhat.com/browse/CNV-36448[CNV-36448]) - [discrete] [id="virt-4-20-ki-webconsole_{context}"] === Web console @@ -205,10 +200,6 @@ include::snippets/technology-preview.adoc[] :!FeatureName: endif::[] -// cnv-61740 - s390x VM fails to boot with SATA CD-ROM -* If you create a VM from a template and select *Boot from CD*, the VM fails to boot and the error `unsupported configuration: SATA is not supported with this QEMU binary` is logged. This occurs because the CD-ROM is automatically mounted as a SATA device, which is not supported on s390x architecture. (link:https://issues.redhat.com/browse/CNV-61740[CNV-61740]) -** As a workaround, navigate to the VM's *Configuration* -> *Storage* tab, select the CD-ROM, and change the interface type from *SATA* to *SCSI*. - // cnv-61957 - GPU devices should not be shown in UI * GPU devices appear in the *Hardware Devices* list for s390x VMs, but GPU support is not available for s390x architecture. You can disregard these list entries. (link:https://issues.redhat.com/browse/CNV-61957[CNV-61957])