How to Perform Cold and Live KVM VM Migration with NFS Shared Storage
This guide explains how to perform both cold and live migration of KVM virtual machines using NFS shared storage, covering prerequisites, step‑by‑step commands, network considerations, and key virsh options to avoid disk corruption and ensure seamless VM movement across hosts.
Introduction
When a KVM host (vm1) runs a virtual machine and another host (vm2) mounts the VM's disk directory via NFS, hot migration can cause disk corruption. Using a dedicated NFS or other shared‑storage server for all KVM hosts prevents this issue.
Prerequisites
All KVM hosts (vm1…vmn) must have the same KVM version installed.
Bridge networking: create a bridge interface (e.g., br0) and attach eth0 to it.
Mount points for the shared storage must be identical on every host.
Cold Migration
Drawbacks :
The VM must be shut down, which interrupts services (or may cause temporary MAC address conflicts if left running).
Migration can take a long time, especially for large disk images.
Steps:
Copy the VM's XML definition and disk image to the target host:
scp /etc/libvirt/qemu/qianyi-bridge-vm.xml kafka-2:/etc/libvirt/qemu/qianyi-bridge-vm.xml</code><code>scp /opt/kvm/vm/qianyi-bridge-vm.qcow2 kafka-2:/opt/kvm/vm/qianyi-bridge-vm.qcow2Define the VM on the target host: virsh define /tmp/<vm-name>.xml Start the VM and verify it runs:
virsh list --all</code><code>virsh start <vm-name>Test network access. Use arping to check for duplicate MAC addresses; if two MACs appear, shut down one VM to leave a single MAC.
Live Migration
Install NFS on a dedicated server (e.g., vm3) and ensure all hosts mount the same shared directory. df -h Typical df -h output shows the NFS mount 192.168.64.12:/opt/kvm on both source and destination hosts.
Execute live migration with virsh migrate:
# Live migration without shared storage</code><code>virsh migrate --live --verbose domain qemu+ssh://192.168.64.11/system --unsafe</code><code>virsh migrate --live --verbose test2-nat-network-2 qemu+ssh://192.168.64.11/system --unsafe # migrate</code><code>virsh migrate --live --verbose test2-nat-network-2 qemu+ssh://192.168.64.14/system --unsafe # reverse migrate</code><code>virsh migrate --live --persistent --undefinesource --verbose myvm qemu+ssh://[email protected]/system --unsafeParameter explanations: --live: perform online migration. --verbose: show detailed progress. qemu+ssh://IP/system: target host connection using SSH; system refers to the libvirt system instance. --unsafe: allow migration without shared storage (useful for testing). --undefinesource: remove the VM definition from the source after migration, but keep the disk files. --persistent: make the VM definition persistent on the destination so it survives host reboots.
Important: The disk element in both source and destination XML files must point to the shared storage directory.
Host Name Resolution
127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4 kafka-1</code><code>::1 localhost localhost.localdomain localhost6 localhost6.localdomain6</code><code>192.168.64.14 kafka-1</code><code>192.168.64.11 kafka-2</code><code>192.168.64.12 kafka-3Images
Network and MAC address observations are illustrated by the following screenshots:
Signed-in readers can open the original source through BestHub's protected redirect.
This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactand we will review it promptly.
Liangxu Linux
Liangxu, a self‑taught IT professional now working as a Linux development engineer at a Fortune 500 multinational, shares extensive Linux knowledge—fundamentals, applications, tools, plus Git, databases, Raspberry Pi, etc. (Reply “Linux” to receive essential resources.)
How this landed with the community
Was this worth your time?
0 Comments
Thoughtful readers leave field notes, pushback, and hard-won operational detail here.
