On Mon, May 23, 2011 at 2:02 PM, Stefan Hajnoczi <stefanha@xxxxxxxxx> wrote: > On Sun, May 22, 2011 at 10:52 AM, Dor Laor <dlaor@xxxxxxxxxx> wrote: >> On 05/20/2011 03:19 PM, Stefan Hajnoczi wrote: >>> >>> I'm interested in what the API for snapshots would look like. >>> Specifically how does user software do the following: >>> 1. Create a snapshot >>> 2. Delete a snapshot >>> 3. List snapshots >>> 4. Access data from a snapshot >> >> There are plenty of options there: >> - Run a (unrelated) VM and hotplug the snapshot as additional disk > > This is the backup appliance VM model and makes it possible to move > the backup application to where the data is (or not, if you have a SAN > and decide to spin up the appliance VM on another host). This should > be perfectly doable if snapshots are "volumes" at the libvirt level. > > A special-case of the backup appliance VM is using libguestfs to > access the snapshot from the host. This includes both block-level and > file system-level access along with OS detection APIs that libguestfs > provides. > > If snapshots are "volumes" at the libvirt level, then it is also > possible to use virStorageVolDownload() to stream the entire snapshot > through libvirt: > http://libvirt.org/html/libvirt-libvirt.html#virStorageVolDownload > > Summarizing, here are three access methods that integrate with libvirt > and cover many use cases: > > 1. Backup appliance VM. Add a readonly snapshot volume to a backup > appliance VM. If shared storage (e.g. SAN) is available then the > appliance can be run on any host. Otherwise the appliance must run on > the same host that the snapshot resides on. > > 2. Libguestfs client on host. Launch libguestfs with the readonly > snapshot volume. The backup application runs directly on the host, it > has both block and file system access to the snapshot. > > 3. Download the snapshot to a remote host for backup processing. Use > the virStorageVolDownload() API to download the snapshot onto a > libvirt client machine. Dirty block tracking is still useful here > since the virStorageVolDownload() API supports <offset, length> > arguments. Jagane, What do you think about these access methods? What does your custom protocol integrate with today - do you have a custom non-libvirt KVM management stack? Stefan -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list