CNV#40187-02: Misc RN Fix

virt/release_notes/virt-4-17-release-notes.adoc

@@ -127,15 +127,9 @@ link:https://access.redhat.com/support/offerings/techpreview[Technology Preview
 //CNV-15028: Nested virt in virt hosts. This feature will remain in tech preview indefinitely.
 * You can now enable link:https://access.redhat.com/solutions/6692341[nested virtualization on {VirtProductName} hosts].
 
-//CNV-33125: Add CPU limits to the UI
-* Cluster admins can now enable CPU resource limits on a namespace in the {product-title} web console under *Overview* -> *Settings* -> *Preview features*.
-
 //CNV-22314: Safe memory overcommitment using `wasp-agent`
 * Cluster admins can now use the `wasp-agent` tool to xref:../../virt/post_installation_configuration/virt-configuring-higher-vm-workload-density.adoc#virt-configuring-higher-vm-workload-density[configure a higher VM workload density] in their clusters by overcommitting the amount of memory, in RAM, and assigning swap resources to VM workloads.
 
-//CNV-31997: PREVIEW - compatibility with ODF Regional DR
-* {VirtProductName} now supports compatibility with {rh-storage-first} (ODF) Regional Disaster Recovery.
-
 [id="virt-4-17-bug-fixes"]
 == Bug fixes
 
@@ -173,10 +167,6 @@ link:https://access.redhat.com/support/offerings/techpreview[Technology Preview
 [id="virt-4-17-ki-virtualization"]
 ==== Virtualization
 
-//CNV-43195: 4.16 - VM migration fails with virError
-* VM migrations might fail on clusters with mixed CPU types. (link:https://issues.redhat.com/browse/CNV-43195[*CNV-43195*])
-** As a workaround, you can set the CPU model at the xref:../../virt/virtual_machines/advanced_vm_management/virt-schedule-vms.adoc#virt-schedule-supported-cpu-model-vms_virt-schedule-vms[VM spec level] or at the xref:../../virt/virtual_machines/advanced_vm_management/virt-configuring-default-cpu-model.adoc#virt-configuring-default-cpu-model_virt-configuring-default-cpu-model[cluster level].
-
 //CNV-36448: 4.16 - Unresolved
 * 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*])