[libvirt-users] Hot cloning & P2V

[Eric Blake]

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 at redhat.com    +1-801-349-2682
Libvirt virtualization library http://libvirt.org