[libvirt] block-backup API for libvirt

[Ian Main]

On Fri, Nov 08, 2013 at 05:13:00PM -0700, Eric Blake wrote:
> On 11/08/2013 01:56 PM, Ian Main wrote:
> > 
> > In qemu there will soon be drive-backup and block-backup commands that
> > allow you to create backups or point-in-time snapshots of VM images.
> > The original feature that drove this was to allow 'image fleecing',
> > which involves creating a light weight mechanism to take a point in time
> > snapshot of the running VM and access that remotely.
> > 
> > You can get a good idea of the API from this post:
> > 
> > http://lists.gnu.org/archive/html/qemu-devel/2013-10/msg02266.html
> > 
> > I would like to see this available via libvirt and wanted to start
> > working on a suitable API.  I'm curious if anyone has any input on how
> > they would like to see this done?  While I have done some work with and
> > on libvirt I'm no expert on the design philosophy behind the APIs so
> > some direction here before I get coding would be much appreciated.
> > 
> >>From what I can tell a volume based API that creates 'backups' and does
> > the NBD export call could work but I'd like to hear if that's
> > reasonable.
> 
> It seems to me that a new API virDomainBlockBackup(domain, disk,
> destination, bandwidth, flags) is probably the right approach, as well
> as enhancing the existing virDomainBlockJob* to report job status and/or
> abort the job early.

OK that sounds good.  How would it look if you wanted to NBD export the
disk?  Would that require a special desitination uri of some sort, or?

Also in order to do that we need to run several commands against qemu
including building a temporary image to store the original blocks.   Is
there an example command which already uses temporary storage that I
could look at?

> For that matter, we need to overhaul the job support.  Right now,
> virDomainBlockJob* assumes you can only have one outstanding job at a
> time, which interferes with the notion of running fleecing from two
> points in time.  Similarly, there can only be one virDomainGetJobInfo
> active.  What we really need is a notion of a job id, a way to query the
> job id most recently created by any existing job-related API, and a way
> to query job status based on id rather than only the most-recently
> started job.

OK I can look at this too.  I need to focus on getting the qemu patches
in and then I'll start tackling all this.

	Ian

 
> -- 
> Eric Blake   eblake redhat com    +1-919-301-3266
> Libvirt virtualization library http://libvirt.org
>