Skip to content
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Original file line number Diff line number Diff line change
Expand Up @@ -30,6 +30,8 @@ include::../modules/ref_sco-supported-storage-providers.adoc[leveloffset=+2]

include::../modules/proc_storage-copy-offload-steps.adoc[leveloffset=+2]

include::../modules/con_sco-warm-migration-performance.adoc[leveloffset=+2]

include::../modules/con_copy-methods-sco.adoc[leveloffset=+2]

include::../modules/con_sco-ssh-advantages.adoc[leveloffset=+2]
Expand Down
28 changes: 28 additions & 0 deletions documentation/modules/con_sco-warm-migration-performance.adoc
Original file line number Diff line number Diff line change
@@ -0,0 +1,28 @@
// Module included in the following assemblies:
//
// * documentation/doc-Planning_your_migration/assemblies/assembly_planning-migration-vmware.adoc

:_mod-docs-content-type: CONCEPT
[id="con_sco-warm-migration-performance_{context}"]
= Disk write activity and warm migration performance for storage copy offload

[role="_abstract"]
Evaluate whether warm migration with storage copy offload reduces final switchover downtime compared to cold migration. To do this, measure the disk write rate of your virtual machines before migrating.

During a warm migration, {project-short} takes periodic Changed Block Tracking (CBT) snapshots while the virtual machine (VM) continues to run. Each snapshot captures the blocks that changed since the previous snapshot. When the disk write rate is high, the resulting change sets are larger. Larger change sets increase the time required to copy each delta.

Warm migration might take longer overall than cold migration while still providing the intended downtime reduction. Evaluate the final switchover downtime against the cold-migration baseline as your primary decision metric. You can evaluate the total elapsed migration time as a secondary metric. If copying the final change set takes longer than a cold migration, warm migration provides no downtime advantage.

The impact of disk write rates on downtime can vary significantly. The following examples illustrate how disk write rates impact downtime:

* A VM writing at 50 kilobytes per second produces minimal change sets. These change sets add little to the switchover downtime.
* A VM writing at 5 megabytes per second accumulates large change sets. This data volume can eliminate the expected downtime savings.

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@mnecas Is it OK to use numbers here? The rates differ by 2 orders of magnitude.

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this is okay, the line before this specifically says these are just examples. The order of magnitude difference here shows two extremes so that one saves downtime and the other doesn't.

[NOTE]
====
High disk write activity can reduce or eliminate the expected downtime benefit of warm migration. Within your tested workload range, the migration might complete correctly without reducing downtime.
====
Comment thread
RichardHoch marked this conversation as resolved.

Before you migrate VMs in a production environment, measure the disk write rate of your storage array. This measurement helps you determine if warm migration provides a downtime advantage over cold migration.

You can evaluate your storage array performance by testing a representative VM with a disk stress tool at varied write speeds. Compare the final switchover downtime against a cold migration to determine the disk write rate threshold. At this threshold, warm migration loses its downtime advantage. Use this threshold to choose between warm and cold migrations for your production VMs.
Comment thread
RichardHoch marked this conversation as resolved.
Loading