1
0
mirror of https://github.com/openshift/openshift-docs.git synced 2026-02-05 12:46:18 +01:00
Files
openshift-docs/modules/migration-mtc-release-notes-1-8-9.adoc
2025-09-12 20:48:40 +01:00

25 lines
2.0 KiB
Plaintext

// Module included in the following assemblies:
//
// * migration_toolkit_for_containers/mtc-release-notes.adoc
:_mod-docs-content-type: REFERENCE
[id="migration-mtc-release-notes-1-8-9_{context}"]
= {mtc-full} 1.8.9 release notes
[id="resolved-issues-1-8-9_{context}"]
== Resolved issues
{mtc-first} 1.8.9 has the following major resolved issues:
.VM restarts migration after the MigPlan deletion
Before this update, deleting the `MigPlan` triggered unnecessary virtual machine (VM) migrations. This caused the VMs to resume, leading to migration failures. This release introduces a fix that prevents VMs from migrating when the `MigPlan` is actively removed. As a result, VMs no longer unintentionally migrate when MigPlans are deleted, ensuring a stable environment for users. link:https://issues.redhat.com/browse/MIG-1749[(MIG-1749)]
.Virt-launcher pod remain in pending after migrating the VM from hostpath-csi-basic to hostpath-csi-pvc-block
Before this update, the `virt-launcher` pod stalled after migrating a VM due to pod anti-affinity conflicts with bound volumes. This resulted in a failed VM migration, causing the virt-launcher pod to get stuck. This release resolves the pod anti-affinity issue, allowing for scheduling on different nodes. As a result, you can now migrate VMs from `hostpath-csi-basic` to `hostpath-csi-pvc-block` without pods getting stuck in a pending state, thereby improving the overall migration process efficiency. link:https://issues.redhat.com/browse/MIG-1750[(MIG-1750)]
.Migration-controller panics due to LimitRange "NIL" found in source project
Before this update, the missing `Min` spec in a LimitRange within the `openshift-migration` namespace caused a panic in the migration-controller pod, disrupting the user experience and preventing successful volume migration. With this release, the migration-controller pod no longer crashes when encountering a LimitRange set to `Nil`. As a result, `rsync` pods now comply with the specified limits, improving the migration process stability and eliminating crashloopbacks in source namespaces.