Live Migration Times Out on a High-Dirty-Rate Database VM
A FusionCompute cluster has eight hosts and shared SAN storage. Each host has two 10 GE ports: one carries storage traffic, the other carries business VM traffic, and live migration shares the business VLAN because no dedicated migration network was built. A SQL Server VM has 96 GB RAM and 24 vCPU and sustains about 3.8 Gbps of write traffic during the evening batch. A planned live migration at 22:00 fails at 94 percent after 240 seconds with a migration timeout. Host CPU is 55 percent and the business link is at 7 Gbps during the attempt. A retry at 22:20 fails at the same point. The administrator proposes disabling migration and using HA restart instead, or powering the VM off for a four-hour maintenance window.
1. Diagnose the migration failure using the memory and network behavior of live migration.
Read the worked answer
Live migration copies memory pages iteratively: an initial full copy, then repeated copies of pages dirtied since the previous pass. It completes only when the remaining dirty set is small enough to be transferred within the final switchover pause. Here the VM writes at roughly 3.8 Gbps and the shared 10 GE business link is already at 7 Gbps, so the bandwidth available to migration is both limited and variable. The 96 GB initial copy and the high dirty rate mean each pass chases new writes; progress stalls near the end and the timeout fires at 94 percent. This is a convergence problem, not a host failure or storage problem. The repeat failure at the same percentage supports that reading. HA restart would not preserve the VM's memory state and is not a maintenance strategy; a four-hour power-off is a fallback, not a diagnosis.
2. Compare three remediation options and their operational risk.
Read the worked answer
Option one is a dedicated migration network, ideally 25 GE, on a separate VLAN, so migration does not contend with business traffic and has predictable bandwidth. Risk is low and the change is reusable for every future migration, but it needs ports and cabling. Option two is to schedule the migration outside the batch window and tune migration settings such as allowed downtime and convergence behavior, plus enable memory compression if supported. Risk is moderate: a longer switchover pause can be visible to the application, and compression costs CPU. Option three is a cold migration with a four-hour outage; risk to service is high but the technical outcome is certain. Option two is the quickest to test, option one is the durable fix, and option three should be a last resort with a rollback plan. Disabling migration entirely would weaken maintenance and HA operations and should be rejected.
3. Design the target state and the validation you would require before the next maintenance window.
Read the worked answer
Build a dedicated migration network on separate physical ports or a separate VLAN with sufficient bandwidth for the largest VM's dirty rate, and verify the path with a test migration of a similarly sized VM. Keep migration traffic off the business VLAN, and monitor bandwidth, migration duration, and switchover pause. Tune the VM's migration policy only after the network fix, because tuning masks a bandwidth problem. Validate during a low-batch period first, then during the batch to prove convergence under realistic load. Define success as migration completing within the agreed window with application latency within service level and no dropped sessions. Keep the cold-migration plan as a documented fallback, but do not present HA restart as equivalent to migration. Finally, check that the same design covers the other large VMs, not just this database.