Architecture and operating model
KVM live migration moves memory and device state to another host while limiting application interruption. With shared storage, both hosts access the same disk image and migration mostly transfers memory state. A non-shared block migration also copies disk data over the network. Bandwidth, failure domains, permissions and rollback differ between these paths.
During pre-copy, memory pages move while the VM remains active, and dirtied pages move again. Convergence slows as dirty rate approaches available throughput. Auto-converge can throttle guest CPU; post-copy starts execution at the destination and fetches missing pages from the source, changing recovery risk if a host fails. Select a mode from maintenance objectives and tested failure scenarios.
Shared storage can shorten transfer time but requires consistent volume identity, locking and access on both hosts. Block migration avoids a common SAN or NFS path but makes disk size and write rate part of the transfer. `--copy-storage-all` copies writable disks, while selective options narrow the set. Validate backing chains and thin provisioning at the destination.
Before a pilot, check CPU compatibility, MTU, TLS, destination pools and free capacity. Measure disk and memory write rates under representative load to project duration. Observe progress, dirty rate, disk throughput and downtime together. A Running state is insufficient: validate application health, disk consistency, network sessions and expected source cleanup.
- 1Compatibility and capacity check
- 2Pre-copy memory and optional disks
- 3Short switchover
- 4Destination validation and source cleanup
Design parameters
- Working set
- Measure RAM size, dirty-page rate and effective network throughput together.
- Disk path
- Validate shared volume identity and locking, or disk size and write rate for block copy.
- Downtime budget
- Set separate limits for switchover, total maintenance and failed-migration rollback.
- Security
- Authenticate and encrypt the migration channel and isolate it from client traffic.
- Convergence policy
- Choose timeout, auto-converge and post-copy from testing rather than defaults.
Platform implementation
Service names are reference points. Scope, defaults, region availability and operating requirements differ; they are not interchangeable guarantees.
| Criterion | Shared storage | Block migration |
|---|---|---|
| Transferred data | Mostly memory and device state | Memory, devices and selected disks |
| Prerequisite | Both hosts see one secured volume | Destination capacity and disk definitions |
| Bottleneck | Dirty pages and storage latency | Disk size, write rate and network |
| Failure domain | Shared storage can affect both hosts | Copy consistency and a longer window |
| Good fit | Frequent maintenance within a cluster | Planned moves between local-storage hosts |
Worked example
For a VM using 128 GiB RAM, dirtying 2 GiB/s and receiving 8 GiB/s effective migration throughput, the first memory pass is about 16 seconds. Later rounds can shrink the dirty set. At 7.5 GiB/s dirty rate, margin is small; measure total time and throttling before promising downtime.
Copying a 4 TiB local disk at a net 500 MiB/s takes about 4×1024×1024/500 = 8,389 seconds, or 2.33 hours, before changed blocks, overhead and switchover. A two-hour window cannot accept that plan; evaluate pre-replication or shared storage.
Example commands: replace lab values and confirm permissions and software versions before use.
virsh domcapabilities --virttype kvm
virsh domblklist app01 --details
virsh migrate --live --persistent --verbose --tls app01 qemu+tls://kvm02/system
virsh migrate --live --persistent --copy-storage-all --verbose --tls app01 qemu+tls://kvm02/system
virsh domjobinfo app01Troubleshooting
| Observation | Likely cause / distinction | Verification |
|---|---|---|
| Migration progress stalls | Memory dirtying or disk writes may approach transfer capacity. | Compare dirty rate, migration throughput and disk writes on one timeline. |
| Destination disk is missing | Pool, path, backing chain or permissions may differ. | Compare destination XML, pool inventory and volume identity with the source. |
| VM runs but application is unreachable | Bridge, VLAN, port profile or a dependency may differ. | Validate NIC XML, bridge/VLAN counters and the application health endpoint. |
Acceptance checks
- Validate CPU model and device compatibility.
- Measure memory dirty rate and disk writes at peak load.
- Check destination capacity, volume identity and permissions.
- Test migration-network MTU, throughput and TLS.
- Record total duration and switchover downtime in a pilot.
- Validate application, disk and network before source cleanup.
Related concepts
Availability versus recovery
High availability aims to keep service running through specified failures with a short interruption; backup recovers lost or corrupted data from an earlier point. A cluster can replicate an accidental deletion to another node. HA therefore does not replace backup. Consider DNS, identity, network, storage and power dependencies together. Successful node failover is insufficient by itself: measure user sessions, application writes and external integrations after the transition as well.
Latency distribution
Latency is the time between starting an operation and receiving its result. An average can hide a small number of very slow operations; medians and p95/p99 percentiles answer different questions. Network RTT, storage waits, processor queues and application processing contribute to end-to-end time. State whether measurements come from the client or server. Check whether increases coincide with traffic growth, maintenance or capacity limits. Record normal and peak-hour baselines before selecting an alert threshold.
Bandwidth and useful throughput
Link capacity differs from useful application throughput. Protocol headers, encryption, retransmissions, small files and storage waits reduce net transfer speed. Keep bits and bytes distinct: 1 Gbit/s corresponds to a theoretical 125 MB/s, not an application performance guarantee. Estimate transfer time as data size divided by measured useful throughput. Observe the network, source reads and destination writes together to locate the bottleneck. Consider temporary slowdowns and competing workloads as well as average speed.
Capacity and usable headroom
Raw capacity is not the capacity available to applications. RAID or erasure coding, filesystems, reserved space, metadata, snapshots and growth headroom are separate deductions. TB and TiB representations also change the displayed number. Write calculations with units, establish protected usable capacity, then subtract operating reserves. Track growth rate as well as current utilization. The projected exhaustion date should leave enough time to procure and deploy additional capacity.
Application consistency
A bootable copy does not prove application-data consistency. Operating-system caches, database logs and write ordering across disks or services affect the result. A crash-consistent copy resembles recovery after an unexpected shutdown; an application-consistent copy follows supported application preparation and write coordination. Validate transaction integrity, relationships between records and application behavior after recovery, rather than only counting files. Confirm backup integration, application version and reported errors before assuming that consistency was achieved.
Failover and failback
Failover moves service to another component; failback returns it to the preferred location. Their risks and sequencing may differ. DNS updates, routing, sessions, replication lag and application dependencies determine user interruption. Define failover triggers, false-alarm behavior and approval for returning service. Simply shutting down a VM does not test every failure type. Measure network, storage and management-plane failures separately.
Primary documentation
Prepared by the Doz Teknoloji technical team using the primary references below. Calculations and lab scenarios state their assumptions; validate the applicable product version before rollout.