[libvirt] block-backup API for libvirt
From what I can tell a volume based API that creates 'backups' and does
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. the NBD export call could work but I'd like to hear if that's reasonable. Thanks! Ian
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. 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. -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
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
participants (2)
-
Eric Blake -
Ian Main