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
  • Consider using [lvmsync](https://github.com/mpalmer/lvmsync) instead of `dd` - it should improve performance and downtime. – neutrinus Mar 06 '14 at 10:57

3 Answers3

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.
andrewfn
  • 3
  • 2
sybreon
  • 7,405
  • 1
  • 21
  • 20
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.

Michael Hampton
  • 244,070
  • 43
  • 506
  • 972
  • This should work for example migrating from RHEL 7 to another RHEL 7, but not from RHEL 6 to RHEL 7. See http://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
  • 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 '15 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 '18 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

os_1
  • 101
  • 2