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