Is there any possible way to perform live migration using KVM/QEMU/libvirt without stopping source VM after migration?

I want to make full consistent backup of VM under KVM hypervisor without stopping of this VM.
So idea is to perform live migration without stopping source VM, than after successful migration stop VM on destination host using completely correct stopping procedure, and make full offline copy of it without interruption of source VM working.

But in default setup, source VM stops working after successful migration, so I have to start it again. Is there any possible way to change this behaviour?

Any suggestions are welcomed.

  • If you voting down question, please describe your reasons. What's wrong with it? – Ivan Olshansky Nov 8 '18 at 14:29
  • Hope someone vote this question up so it will remain attractive for answers. Thanks in advance! – Ivan Olshansky Nov 8 '18 at 14:38
  • This is the wrong way to back up a running VM. Instead you freeze it, which briefly prevents writes to the disk, take a snapshot of the storage, and then unfreeze it, which takes a fraction of a second and does not require migration. You then back up the storage snapshot. All reasonable hypervisors support this operation. Check your documentation. – Michael Hampton Nov 8 '18 at 15:10
  • @MichaelHampton, I don't want to make snapshot of the disk of working VM. I want to stop this VM in fully correct way and THEN copy its disk. But I also want main VM to be online full time during this process. So I NEED to have 2 instances of this VM. – Ivan Olshansky Nov 8 '18 at 15:33
  • You don't need two instances of this VM. You need only one. The correct way IS the way I described above. – Michael Hampton Nov 8 '18 at 15:43

This isn't possible with live migration - there's no way to prevent libvirt switching execution to the target VM & tearing down the source VM once migration completes.

Fortunately you don't need migration in order to do full disk backups on running VMs. Libvirt / QEMU has support for live disk snapshotting.

Essentially you tell QEMU to add a temporary qcow2 overlay to the existing disk, so writes start going to the overlay disk. Now you can safely take a backup of the original base disk image, using cp, rsync, $whatever. Once you've taken a backup you can tell QEMU to merge the overlay back into the base image, pivot writes to the base image, and throw away the temporary overlay. Example commands are shown here:


If you have multiple disks on the VM and want the snapshot to be at a consistent point in time across all disks, then you can use the QEMU guest agent to quiesce guest I/O while adding the overlays. The guest agent is not required if you only have a single disk, as QEMU can do the disk pivots atomically in that case.

  • But what if I want to make backup of properly shut down VM? If I use snapshot method I in fact get state of VM, as it was just powered of without chance to execute all shut down scripts. Migration potentially give possibility to execute all these scripts on clone VM before actually power it off. – Ivan Olshansky Nov 13 '18 at 15:25

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.