I have a KVM guest that I need to migrate from one host to another. The migration does not need to be done hot. Its storage is currently backed by LVM block devices, with a bridged network adapter. Both servers have the same kernel, version of libvirt, qemu, etc. Whats the easiest way to do this?

My guess at this is:

dd the block devices from server A to server B
export the xml VM definition on A, copy it to B
edit the xml to refer to the new physical device names
create the machine referencing that xml file
  • Consider using lvmsync instead of dd - it should improve performance and downtime. – neutrinus Mar 6 '14 at 10:57
up vote 7 down vote accepted

You are right. I have done this several times. I used netcat to image the drives across the network. This is the method that I used:

  1. Create the logical volume on the target. It should be the same size as the source volume.
  2. Run nc -l 1234 | dd of=/dev/<vgname>/<lvname> on the target host. This tells netcat to listen on the network port and pipe everything to the logical volume.
  3. Shutdown the source machine cleanly to write everything to disk.
  4. Run dd if=/dev/<vgname>/<lvname> | nc <targetip> 1234 on the source host. This tells netcat to pipe everything over the network to the target host.
  5. Go fetch a cup of coffee. This takes a few minutes depending on your volume size and network speed.
  6. Copy the xml definitions from /etc/libvirt/qemu/ from the source to the target.
  7. Edit the storage portion of the xml file and any other necessary bits such as network bridge name if they are different.
  8. Reload libvirt on the target to read the xml. An /etc/init.d/libvirt-bin reload should do the trick (or systemctl restart libvirtd for distributions that use systemd)
  9. Start-up the machine on the target host.
  • The migrate option on virt-manager wouldn't work for this? – Jason Axelson Mar 31 '11 at 21:21
  • i believe that it'll only work for network shared images i.e. both hosts must be able to access the same image. – sybreon Apr 5 '11 at 14:35

KVM (since qemu 1.3) now includes storage migration functionality, so it's no longer necessary to do any of the hackery shown in the older answers. Just migrate the VM as you normally would, for instance virsh migrate "Guest Name" qemu+ssh://dest-hypervisor/system or click the nice buttons in your GUI of choice.

  • It would be helpful if you'd provide a version of KVM/Qemu this applies to. On my system (Ubuntu 12.04) this does not yet work. – tex Mar 6 '14 at 5:54
  • @tex Storage migration was added in qemu 1.3. – Michael Hampton Mar 6 '14 at 10:49
  • This should work for example migrating from RHEL 7 to another RHEL 7, but not from RHEL 6 to RHEL 7. See fedoraproject.org/wiki/Features/Virt_Storage_Migration – Diego Mar 24 '15 at 10:00
  • @Diego Right, you need the feature on both ends. – Michael Hampton Mar 24 '15 at 14:15
  • This seems to only works for online migrations as of virsh 1.2.2 and qemu 2.0.0. It looks like offline migrations don't support copying non-shared storage. – vimalloc Sep 14 '15 at 22:58

I followed a somewhat similar approach with differences in detail since i needed to pipe the machineover an insecure connection and used virsh:

  1. share pubkey between the two hosts with ssh-copy id root@newserver from "oldserver"
  2. create Logical Volume on taget
  3. Shutdown source
  4. Pipe the volume to the target host with dd if=/dev/<vgname>/<lvname> | ssh root@targethost 'dd of=/dev/<vgname>/<lvname>'
  5. dump the xml definitions virsh dumpxml <machinename> dump.xml
  6. Transfer xml-file scp dump.xml root@targethost:/root/
  7. Edit the file with an editor of your choice
  8. Define the machine on target virsh define dump.xml the machine is then created from the xml. Do NOT use virsh create machine, then the machine has to be redefined after a reboot.
  9. virsh start machinename

If don't have internet-connection with NAT on the new machine, make sure that ip-forwarding is enabled.

On Ubuntu nano /etc/sysctl.conf uncomment net.ipv4.ip_forward=1

Your Answer


By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.