Hyper-V Live Migration with RDMA enabled: unclear downtime threshold during final memory copy

Question

Live Migration of a small application VM with RDMA enabled

I am planning to move a small application running in a Hyper-V VM between two hosts using Live Migration, with the goal of no perceptible downtime for users. The research available to me confirms that Live Migration is a documented zero-downtime feature, and that RDMA (SMB Direct) can be used to speed up the memory transfer phase.

What is unclear

Microsoft's documentation describes migration time as proportional to VM memory size and available network bandwidth, but I cannot find any documented threshold or guarantee for the brief pause during the final memory copy phase when RDMA is enabled. Community reports mention a few seconds of downtime in that phase, but this does not appear to be officially confirmed, so I cannot tell whether enabling RDMA actually reduces that final pause or only speeds up the bulk transfer.

Constraints

Both hosts run the same Hyper-V version with identical virtualization configuration, as required. The application is latency-sensitive enough that even a multi-second freeze during cutover would be noticeable.

1. Does enabling RDMA for Live Migration measurably shorten the final memory-copy pause, or only the overall migration duration?

2. Is there any documented or supportable downtime threshold for the cutover phase, or is it purely dependent on dirty-page rate and bandwidth?

3. What is a practical way to measure the actual cutover pause on a test pair of hosts before migrating the production VM?

Tasadduq Burney · Answer

Answer
Enabling RDMA (SMB Direct) for Hyper‑V Live Migration shortens the overall migration time and can modestly reduce the final memory‑copy pause, but there is no documented guaranteed downtime threshold for the cutover phase.
Confirmed facts

RDMA offloads memory page transfers to the NIC, lowering CPU overhead and increasing bulk‑transfer throughput.
The final pause (downtime) occurs while the remaining dirty pages and VM state are synchronized; its length depends on the dirty‑page rate relative to the available bandwidth.
Microsoft’s documentation does not publish a fixed downtime limit for this phase; the duration is dynamic.

Likely explanation
Because RDMA reduces the latency of each page transfer, the final synchronization of the last dirty pages can finish a few milliseconds faster than with plain TCP/IP. The effect is noticeable only when the dirty‑page rate is low enough that the bulk transfer already converges quickly; under heavy memory churn the pause remains dominated by the rate of new dirty pages.
Steps to verify on a test pair

Confirm RDMA is active: Get-NetAdapterRdma | Where-Object {$_.Enabled -eq $true} on both hosts.
Perform a test Live Migration of a representative VM while monitoring Event ID 18050 (Live Migration completed) in the Hyper‑V‑VMMS log; note the TotalDuration and Downtime fields.
From a client inside the VM (or a separate monitoring host) run a continuous ping or a latency‑tool (e.g., ping -t or PathPing) to the VM’s IP and record any lost packets or latency spikes during migration.
Compare the measured downtime with and without RDMA (disable SMB Direct temporarily) to see the delta.

Missing diagnostic detail
To predict whether the pause will be below your perceptible threshold, you need the observed dirty‑page rate (memory churn) of the application VM under peak load. If you can provide that rate (e.g., MB/s of dirty pages), we can advise whether the expected pause will stay within your limits.

Hyper-V Live Migration with RDMA enabled: unclear downtime threshold during final memory copy

Live Migration of a small application VM with RDMA enabled

What is unclear

Constraints

1 answer

Answer

Confirmed facts

Likely explanation

Steps to verify on a test pair

Missing diagnostic detail

Your perspective belongs here.

0 question comments