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

[Stefan Hajnoczi]

On Mon, May 23, 2011 at 2:02 PM, Stefan Hajnoczi <stefanha at gmail.com> wrote:
> On Sun, May 22, 2011 at 10:52 AM, Dor Laor <dlaor at 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
> 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