[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [libvirt] [Qemu-devel] [RFC] live snapshot, live merge, live block migration

On Sun, May 22, 2011 at 10:52 AM, Dor Laor <dlaor redhat com> 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

If snapshots are "volumes" at the libvirt level, then it is also
possible to use virStorageVolDownload() to stream the entire snapshot
through libvirt:

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>

>> 5. Restore a VM from a snapshot

Simplest option: virStorageVolUpload().

>> 6. Get the dirty blocks list (for incremental backup)
> It might be needed for additional proposes like efficient delta sync across
> sites or any other storage operation (dedup, etc)
>> We've discussed image format-level approaches but I think the scope of
>> the API should cover several levels at which snapshots are
>> implemented:
>> 1. Image format - image file snapshot (Jes, Jagane)
>> 2. Host file system - ext4 and btrfs snapshots
>> 3. Storage system - LVM or SAN volume snapshots
>> It will be hard to take advantage of more efficient host file system
>> or storage system snapshots if they are not designed in now.
> I agree but it can also be a chicken and the egg problem.
> Actually 1/2/3/5 are already working today regardless of live snapshots.
>> Is anyone familiar enough with the libvirt storage APIs to draft an
>> extension that adds snapshot support?  I will take a stab at it if no
>> one else want to try it.
> I added libvirt-list and Ayal Baron from vdsm.
> What you're asking is even beyond snapshots, it's the whole management of VM
> images. Doing the above operations is simple but for enterprise
> virtualization solution you'll need to lock the NFS/SAN images, handle
> failures of VM/SAN/Mgmt, keep the snapshots info in mgmt DB, etc.
> Today it is managed by a combination of rhev-m/vdsm and libvirt.
> I agree it would have been nice to get such common single entry point
> interface.

Okay, the user API seems to be one layer above libvirt.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]