From 6a3d2c497e4efd3e10f150680f28d8e531f58320 Mon Sep 17 00:00:00 2001 From: "A.Arnold" Date: Tue, 4 Nov 2025 14:04:05 +0000 Subject: [PATCH 1/3] MTV-3676: Add note that there are performance issue for Storage Copy Offload Signed-off-by: A.Arnold --- documentation/modules/known-issues-2-10.adoc | 12 +++++++++++- 1 file changed, 11 insertions(+), 1 deletion(-) diff --git a/documentation/modules/known-issues-2-10.adoc b/documentation/modules/known-issues-2-10.adoc index e33f6fa0a52..5d24540b943 100644 --- a/documentation/modules/known-issues-2-10.adoc +++ b/documentation/modules/known-issues-2-10.adoc @@ -11,7 +11,7 @@ .Raw Device Mapping files prevent `copyoffload` migration of NFS-based VMs -If you try to migrate an NFS-based VM by using the `copyoffload` method, the `vmkfstools` command-line utility attempts to use the fallback method because NFS is file-based. However, NFS datastores do not support Raw Device Mapping (RDM) pointer files, and `vmkfstools` creates RDM files as cloning targets. +If you try to migrate an NFS-based VM by using the `copyoffload` method, the `vmkfstools` command-line utility attempts to use the fallback method because NFS is file-based. However, NFS datastores do not support Raw Device Mapping (RDM) pointer files, and `vmkfstools` creates RDM files as cloning targets. *Workaround:* You can use one of the following migration methods to address the limitation: @@ -24,5 +24,15 @@ If you try to migrate an NFS-based VM by using the `copyoffload` method, the `vm When you create an Open Virtual Appliance (OVA) provider in the MTV UI, `ConnectionTestFailed` error messages are displayed before the provider status changes to `Ready`. The error messages are misleading and do not accurately reflect in-progress status of the connection. link:https://issues.redhat.com/browse/MTV-3613[(MTV-3613)] +.Storage-Offload ignores "max_vm_inflight" value when limiting active migrations to 2 + +Copy-offload migration plans may fail when more than two migrations are triggered simultaneously on a single `ESXi` host. This was observed in tests using 10 and 50 VMs (each with two 50GB disks) on a single `ESXi` host running vSphere 7.0.3. + +The core problem stems from an incorrect scheduling cost function during storage-offload migrations. This miscalculation leads to multiple populate-pods starting concurrently on the same `ESXi` host, even when the configured internal limit (`max_vm_inflight`) is set to *2*. + +**Impact:** + +Because VMware's underlying disk utility, vmkfstools, enforces a strict limit of 2 active copy operations per ESXi host, exceeding this limit results in errors and plan failure. Consequently, customers attempting single-host storage-offload migrations for multiple VMs at once may experience parallel migration failures, negatively impacting overall migration stability and user experience. link:https://issues.redhat.com/browse/MTV-3630[(MTV-3630)] + //For a complete list of all known issues in this release, see the list of link:https://issues.redhat.com/issues/?filter=12472621[Known Issues] in Jira. From 056cac783f5b774ffecc21aa5ba129ea6d46bcbf Mon Sep 17 00:00:00 2001 From: Andy Arnold Date: Thu, 6 Nov 2025 11:55:34 +0000 Subject: [PATCH 2/3] Update documentation/modules/known-issues-2-10.adoc --- documentation/modules/known-issues-2-10.adoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/documentation/modules/known-issues-2-10.adoc b/documentation/modules/known-issues-2-10.adoc index 5d24540b943..12d4dff800b 100644 --- a/documentation/modules/known-issues-2-10.adoc +++ b/documentation/modules/known-issues-2-10.adoc @@ -28,7 +28,7 @@ When you create an Open Virtual Appliance (OVA) provider in the MTV UI, `Connect Copy-offload migration plans may fail when more than two migrations are triggered simultaneously on a single `ESXi` host. This was observed in tests using 10 and 50 VMs (each with two 50GB disks) on a single `ESXi` host running vSphere 7.0.3. -The core problem stems from an incorrect scheduling cost function during storage-offload migrations. This miscalculation leads to multiple populate-pods starting concurrently on the same `ESXi` host, even when the configured internal limit (`max_vm_inflight`) is set to *2*. +The core problem stems from an incorrect scheduling cost function during storage-offload migrations. This miscalculation leads to multiple populate-pods starting concurrently on the same `ESXi` host, even when the configured internal limit (`max_vm_inflight`) is set to *2*. Running more than one disk copy operation simultaneously on the same `ESXi` host significantly risks this failure, leading to errors and overall migration instability. This is especially relevant when migrating multiple VMs, each potentially having multiple disks, from a single `ESXi` host. **Impact:** From 8dbb0af5ad6981bcd83cf021058a64c51e079e10 Mon Sep 17 00:00:00 2001 From: Andy Arnold Date: Thu, 6 Nov 2025 11:56:04 +0000 Subject: [PATCH 3/3] Update documentation/modules/known-issues-2-10.adoc --- documentation/modules/known-issues-2-10.adoc | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/documentation/modules/known-issues-2-10.adoc b/documentation/modules/known-issues-2-10.adoc index 12d4dff800b..ca9f5d95047 100644 --- a/documentation/modules/known-issues-2-10.adoc +++ b/documentation/modules/known-issues-2-10.adoc @@ -26,9 +26,7 @@ When you create an Open Virtual Appliance (OVA) provider in the MTV UI, `Connect .Storage-Offload ignores "max_vm_inflight" value when limiting active migrations to 2 -Copy-offload migration plans may fail when more than two migrations are triggered simultaneously on a single `ESXi` host. This was observed in tests using 10 and 50 VMs (each with two 50GB disks) on a single `ESXi` host running vSphere 7.0.3. - -The core problem stems from an incorrect scheduling cost function during storage-offload migrations. This miscalculation leads to multiple populate-pods starting concurrently on the same `ESXi` host, even when the configured internal limit (`max_vm_inflight`) is set to *2*. Running more than one disk copy operation simultaneously on the same `ESXi` host significantly risks this failure, leading to errors and overall migration instability. This is especially relevant when migrating multiple VMs, each potentially having multiple disks, from a single `ESXi` host. +Copy-offload migration plans may fail when more than two migrations are triggered simultaneously on a single `ESXi` host. This was observed in tests using 10 and 50 VMs (each with two 50GB disks) on a single `ESXi` host running vSphere 7.0.3. The core problem stems from an incorrect scheduling cost function during storage-offload migrations. This miscalculation leads to multiple populate-pods starting concurrently on the same `ESXi` host, even when the configured internal limit (`max_vm_inflight`) is set to *2*. Running more than one disk copy operation simultaneously on the same `ESXi` host significantly risks this failure, leading to errors and overall migration instability. This is especially relevant when migrating multiple VMs, each potentially having multiple disks, from a single `ESXi` host. **Impact:**