On 09/22/2011 06:34 AM, smain kahlouch wrote:
Hi all, I guess my question is stupid and has been asked a thousand times but i was wondering if it's possible to do the following things: - Cloning of a running virtual machine (hot copy)
You can use 'virsh save' (aka virDomainSave) to save the state of a VM, copy that file, then 'virsh save-file-edit' to tweak the associated xml of the copy, so that 'virsh restore' of the original file resumes the original and 'virsh restore' of the copy resumes a hot clone. This isn't quite live (as you have downtime between the save and restore, on the order of seconds, and you end up with a new qemu process which means no seamless migration of any vnc or spice connection to the old process), but at least it doesn't lose VM state. I'm hoping to enhance this further in future libvirt so that the savevm step can reuse the original qemu instead of requiring a restore step that starts a new qemu process.
With libvirt 0.9.6, you can also do this: 'virsh snapshot-create --disk-only' (aka virDomainSnapshotCreateXML) which creates qcow2 wrappers around a read-only base image for all the disk images, with very minimal downtime of the guest (the guest is paused for only a fraction of a second, and the same qemu process stays live so you don't lose connection to vnc or spice). From there, you can create new qcow2 wrappers that target the same read-only base disk images, and start up a new guest via new xml, such that you have two guests that have branched from the same point in time of disk contents; although be aware that you did lose VM state (anything in RAM in the original guest will not be present in the cloned guest). The new guest will have to run fsck (it inherited disks in only a crash-consistent state, rather than a clean boot state - at least until future qemu makes it possible to request via a guest agent that the guest quiesce its disks prior to a snapshot operation). Once the new guest is running, you can then use 'virsh blockpull' to flatten the dependency, so that the new guest's qcow2 disk images no longer depend on the base image of the original guest, at which point you have two truly independent guests, with the second created as a hot-clone of the first. And someday, when (if?) qemu adds the ability to merge qcow2 deltas back into the original backing image (that is, to undo the disk snapshot fork), we can make the process even nicer (no change in filenames for the original guest after the second guest has cleanly completed blockpull, so that the original guest is not forced to use qcow2 disk images).
- Migrate a physical server to a virtual one.
Check out the virt-p2v project. It's rather complicated - it's a one-way conversion (once you have a virtual VM running from the state of the previous physical server, you can't convert back to physical), and requires offline conversion (that is, the process involves booting a liveusb instead of the server itself, so that the conversion is done on stable disks that are not in-use by a live server).
-- Eric Blake eblake@xxxxxxxxxx +1-801-349-2682 Libvirt virtualization library http://libvirt.org
