On 02/02/2013 08:51 PM, harryxiyou wrote: Libvirt snapshots are designed to be an abstraction around whatever the hypervisor can provide. It is flexible enough to cover both internal snapshots (something that qcow2 definitely supports, but it also sounds like sheepdog supports internal snapshots, based solely on what I've read from your comments; but I have no actual experience with sheepdog snapshots myself). Libvirt snapshots are designed to cover as much as the entire state of a guest: all disk state, and also all RAM state needed to restore a running guest back to the same point in time. But, while the design aims to be flexible, the implementation has to catch up to the design. Sheepdog, on the other hand, is a storage protocol. So at most, it can only take snapshots of a single disk state (it probably cannot store the RAM state of a guest that is using the disk, and if you have a guest with more than one sheepdog disk image, it takes metadata outside of sheepdog to coordinate if you are taking a snapshot of a guest across all of its disks at once). Again, I haven't done it myself, so I'm not sure what has been wired into qemu yet. For a running guest, the question boils down to whether the HMP command 'savevm' is wired up to support sheepdog images (if so, qemu would automatically create a sheepdog internal snapshot as part of saving vm state). I also know that people are working on qemu patches to expose more functionality and control over portions of the overall domain snapshot process, so that it would be possible to create a sheepdog snapshot of a disk in isolation without having to bundle it as part of the 'savevm' command. For an offline guest, libvirt does not yet drive 'collie' to create any sheepdog snapshots; I don't know if 'qemu-img' has that capability either. In other words, you are treading on frontier territory, where you may find that a lot of things have not been coded up yet. -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org