[libvirt] question about save/restore domain

[Eric Blake]

On 07/03/2012 02:44 PM, Zeeshan Ali (Khattak) wrote:

> Yeah, this feature is about cloning the VM but using a single file
> that has everything about the domain: disk, ram and the config.

Unfortunately, there is no single-file format that represents the state
of a qemu domain; it really is the combination of the libvirt XML plus
the state of all the disk files, so you may indeed need to create your
own tarball or other file format that wraps all the pieces of state into
a larger collection that can be passed as a single file.

> 
>>  The former is already possible, the latter is
>> on my wishlist of cool things where it would be nice to add better
>> libvirt support.  Another thing to worry about with the feature request
>> of online cloning is what happens if the guest has saved state related
>> to the original (for example, dmidecode information in the guest can see
>> the UUID assigned by the host, but cloning implies creating a new domain
>> with a new UUID).

For offline cloning, we have libguestfs that has the ability to scrub a
disk image to remove some of these artifacts of a clone needing to start
from different state than the parent (things such as clearing out the
random number seed, the hardware MAC address, and so on); see
virt-sysprep for some ideas on the sort of things worth altering in a
clone.  One of the problems of online cloning, though, is that it
becomes extremely difficult to say which things in the guest memory
correspond to file contents that an offline scrub was able to clean.  If
you simplify the problem slightly, by saying that the clone can continue
to run from the same UUID and name but under a different qemu:///session
(that is, the UUID is no longer globally unique, but it still remains
unique between the distinct qemu:///session instances that are managing
the original and the clone; and similarly, that user-space networking is
set up so that reuse of the same hardware MAC between the two
qemu:///session instances will not collide on the real network), then I
suppose that save/restore could be used as a form of online cloning,
without quite as many hurdles as what it would take to do a live clone
all within the same libvirtd instance.

> 
> The plan was to do the latter (online cloning) but since its not
> already possible and IMO it might be too much work for Jovanka to
> handle within the GSoC timeline (keeping in mind that half of the time
> is already gone), we can drop the "saving of RAM/state" part for now
> at least.
> 
> Which API should we be using for offline cloning? Recall that we want
> to have it all in one file. If thats not possible, I guess we have to
> manually put the config and disk in a tarball and on loading machine,
> we create the new domain with that config and put the disk image in
> the right place?

For online cloning:
If you are going to simplify the problem by using separate
qemu:///session instances for the original and the clone, then an online
clone is indeed possible by transferring the save image created by
'virsh save' as well as a copy of all the disk images in use at the time
of the save.  If you are using all qcow2 images, and don't mind dealing
with internal snapshots yourself (since libvirt does not yet have
virStorageVol* API for nicely dealing with internal snapshots when
cloning a qcow2 image), it might also be possible to use 'virsh
snapshot-create' to create a system checkpoint, then 'virsh
snapshot-dumpxml' to dump the snapshot, which you can then modify in
order to redefine it into a snapshot tied to a new domain, then 'virsh
snapshot-revert' to load that snapshot (or use the underlying
virDomainSnapshot* API that the various virsh commands are wrapping);
but I haven't tried doing it myself to see how many tweaks are really
required to get the pieces to work.

If you are looking at offline cloning, you may want to look into how
virt-manager has already solved the problem.  It involves cloning each
of the disk images and creating a new domain pointing to each of the clones.

If you have the premise of shared storage for backing files, it might
also be possible to take a disk snapshot of a domain, then have both the
original and the clone use new wrapping qcow2 files that both point to
the same backing file, so that you don't have to copy the entire disk
image but just manage the two different deltas built atop the same
common base.

-- 
Eric Blake   eblake at redhat.com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 620 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20120703/2823c7ae/attachment-0001.sig>