Live Migrations Get Slower Over Time: It’s the Memory Dirty Rate, Not the Network

Live migrations get slower over time because the VM keeps dirtying memory faster than the network can send it. It’s not your switch. It’s not disk cache. It’s the dirty page rate climbing while the migration runs.

Measure it before you guess

Run a migration and watch the memory transfer graph in the Proxmox task log. You’ll see the transferred bytes shoot up, then crawl. The crawl is the problem. That’s the VM writing to memory faster than the migration can copy it out. On a two-node cluster with 10GbE, a Windows VM with 16GB RAM and a busy SQL server will do this every time.

To confirm, run this on the source node while the migration is stuck:

grep -E 'dirty|Migration status' /var/log/syslog | tail -20

If you see the dirty rate climbing while the transfer rate stays flat, that’s your bottleneck. The migration is chasing a moving target.

Why it gets worse with each run

Every migration leaves the VM’s memory in a slightly different state. The guest OS caches more, the page file grows, and services that were idle before are now active. So the dirty rate on the next migration is higher. It’s not cumulative damage—it’s just that your VM is busier now. If you’re migrating the same VM back and forth to test, each run looks slower because the workload has changed.

The fix that actually works

Stop trying to tune the network. Instead, reduce the dirty rate during migration. Options:

• Pause the VM’s heavy services right before migrating. A quick systemctl stop on the database or web server drops the dirty rate to near zero.
• Use migrate with the --with-local-disks flag if storage is local, so disk I/O doesn’t compete with memory transfer.
• Schedule migrations during low activity. A VM at 2 a.m. migrates in seconds; the same VM at noon takes minutes.

If you can’t stop services, add more bandwidth. But 10GbE is usually enough—the problem is the VM, not the pipe. I’d rather pause a service for 30 seconds than spend an hour tweaking migration settings.

Don’t overthink it

This is a homelab, not a datacenter. If a migration takes 5 minutes instead of 2, who cares? Unless you’re doing HA failover or live maintenance, just schedule it for off-hours. The real fix is knowing why it’s slow so you stop blaming the network. Check the dirty rate, pause the noisy service, move on.

Related: Proxmox HA Load Balancing: It Doesn’t Rebalance, and Here’s the Script to Do It.