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@xxxxxxxxxx +1-919-301-3266 Libvirt virtualization library http://libvirt.org
Attachment:
signature.asc
Description: OpenPGP digital signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list