2

My team has recently been tasked with improving the virtualization infrastructure at the company and one thing we're looking into doing is speeding up migrations. We use local storage only on all VM Hosts. One challenge is that we have thousands of hosts running different versions (sad face) of CentOS, KVM, libvirt, and qemu. All guests are CentOS as well. The lowest versions we're running are:

  • CentOS 5.6
  • Kernel 2.6.18
  • libvirt 1.0.0
  • qemu 1.1.0

The current tool used to do migrations essentially uses netcat to send over the disk image file(s) and runs the appropriate virsh commands to bring the guest up on the new host (in addition to some config management tweaking).

We're trying to find ways to reduce guest downtime and/or speed up the transfer itself by any creative means necessary. We've spent several days gobbling up information from various corners of the interwebs, but are curious if the fine denizens of Serverfault can share some knowledge. We can use shared storage temporarily as a middle man if need be, but aside from changing hypervisors or implementing shared storage for all hosts anything is fair game.

A few current working ideas we have to explore:

  • Snapshot the guest, copy base image to new host, shutdown guest, copy snapshot to new host, commit snapshot on new host, delete snapshot, start
  • Explore using shared storage in some way as a middle man temporarily. Unsure at this point on details, using something like temporarily mounted glusterfs shares is an idea.
  • Copying the disk image files over while the VM is live, shutdown guest, then using rsync to copy the changed bits.

We're open to having different methods/tools that only support newer versions of kvm/qemu/libvirt but would like to be able to move the older stuff in the best way possible as well.

Hoping some folks can share some examples of what they've done! Thanks.

  • Putting the VM's disk image on GlusterFS is a very bad idea, even temporarily. Try NFS instead (the latency shouldn't be too bad if it's on the same network) – André Borie Aug 18 '15 at 22:03
  • Why not use virsh live migration with storage? I use something like: virsh migrate --live --copy-storage-all --undefinesource --verbose --xml /tmp/host.xml host qemu+ssh://other/system. You'll need to copy host.xml and define host and storage on the new system. It works on Centos7/6, have not tried it in 5. – nkms Aug 18 '15 at 22:34
  • Thanks for the migrate --live command, we'll look into that more. One issue is that our hosts are on different subnets but we can create the idea of "clusters" of hosts that are on the same subnet. This will be useful for overprovisioning and needing to move things off one host for sure. – userdel Aug 19 '15 at 14:55
  • Andre, can you elaborate on why using GlusterFS is a bad idea please? Thanks! – userdel Aug 19 '15 at 14:55
  • live storage migrate will not work on the EL5 hosts – dyasny Aug 19 '15 at 15:26
1

You can wait a little longer, for oVirt to support hyperconverged virtualization, and migrate over. You will have a free opensource KVM based virtualization system, with local storage as gluster volumes, and central management for all. A bit of yum-updatesd or puppet/ansible/whatever, and the version control over the hosts is also established.

  • Can you define a "little longer"? =) I'm assuming there will be some gotchas here and requirements we may not have in place, so I'm hesitant to even consider banking on a solution like this. Nevertheless, I'm interested in learning more! – userdel Aug 19 '15 at 14:57
  • This is the featurepage: ovirt.org/Features/GlusterFS-Hyperconvergence The target is v3.6, which is the next version to come out, unless they decide to postpone for some reason. To get more details, email users@ovirt.org, engineers and PMs are both watching and replying to the list – dyasny Aug 19 '15 at 15:26

Your Answer

By clicking "Post Your Answer", you agree to our terms of service, privacy policy and cookie policy

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