Merge pull request #99145 from danielclowers/CNV-57754_02

CNV#55754_02: Misc 4.20 RN fixes

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])