7

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
1
  • Consider using lvmsync instead of dd - it should improve performance and downtime.
    – neutrinus
    Mar 6, 2014 at 10:57

3 Answers 3

10

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.
2
  • The migrate option on virt-manager wouldn't work for this? Mar 31, 2011 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, 2011 at 14:35
9

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.

4
  • 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, 2015 at 10:00
  • @Diego Right, you need the feature on both ends. Mar 24, 2015 at 14:15
  • 1
    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, 2015 at 22:58
  • The migrate option on Debian/Ubuntu virt-manager is greyed out, despite all hosts being virt-manager 1.4.0, and KVM 2.8. I don't know why.
    – mcr
    Aug 12, 2018 at 16:39
0

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

You must log in to answer this question.