Backup a VM's disk image while it is running, with zero downtime. For more details, see:
Nothing beyond the initial test day setup (basically a function F18 VM).
How to test
- Start your VM, connect to the graphical console with virt-manager. Log in to your guest.
- On the host, create a live snapshot of the guest:
# virsh snapshot-create-as f18 snapshot1 "snapshot for backup" --disk-only --atomic --no-metadata
- Your guest is now running off a sparse qcow2 image. Merge the original disk info into the sparse snapshot:
# virsh blockpull --domain f18 --path /var/lib/libvirt/images/f18.snapshot1
- Watch the progress of this operation:
# virsh blockjob --info f18 /mnt/data/devel/images/f18.snapshot1 Block Pull: [ 35 %] # virsh blockjob --info f18 /mnt/data/devel/images/f18.snapshot1 Block Pull: [ 39 %]
- While this operation is taking place, connect to the guest and touch a create a few files in $HOME
- When the job has finished, the above blockjob command will return empty output
- Move the original disk image to your backup location
# mv /var/lib/libvirt/images/f18.img /my/backup/dir
- Verify that the guest is still accessible, and all files can be read ('find /' should be sufficient)
If you want to get back to your original VM image name, you can now do:
# virsh snapshot-create-as f18 snapshot2 "snapshot for backup" --disk-only --atomic --no-metadata --diskspec vda,file=/var/lib/libvirt/images/f18.img
Then continue with the above steps to merge your changes in the original image, and delete the intermediate f18.snapshot. Your disk f18.img will still be converted to qcow2 however (but that's a good thing!)
Optionally, you can shutdown the VM, and edit the XML using 'virsh edit' like usual
No obvious errors, guest appears to be functioning correctly after all the steps.