On Mon, Mar 21, 2016 at 01:18:19PM +0300, Maxim Nestratov wrote:
Hi all,
It's been already quite a long time since qemu implemented QMP
"drive-backup" command to create block devices backups. Even more, since
qemu 2.4 there is a possibility to create incremental backups. Though it is
possible to backup all attached to a domain disk drives by combining them
into a single QMP transaction command, this way of creating them, not to
mention managing, remains inconvenient for an end user of libvirt. Moreover,
creating a single drive backup via QMP interface isn't handy either. That
said, it looks reasonable to introduce a *new backup API* based on QMP
"drive-backup" facilities.
Though we can start from a single simple function, allowing to create a disk
backup by means of QMP "drive-backup" command, I'd like to discuss here
the
level of management libvirt could provide for backup operations. To begin
with, here is the preliminary list of possible functions that I think make
sense for libvirt API.
virDomainCreateBackup - which creates a backup full/incremental of
all/selected disks,
virListBackups - which lists all backups created for a particular
domain/target,
virRestoreBackup - which restores all/selected disks from a backup,
virDeleteBackup - which deletes all/selected disks from a backup.
It looks like backup management functions, except create one, shouldn't be
or might not be bound to a particular domain and we could possibly leverage
storage pool API with some extension. Specifically, volume definition could
be extended with necessary meta data related to backups.
The *question* is: if the whole idea about this new API as described above
or something similar makes sense?
Well we certainly don't want applications going directly to the QMP
monitor command to achieve this. So given demand for this kind of
feature, some kind of facility will be needed in libvirt. The question
is just what any API would look like.
If yes, then let's find out requirements for it (if any) and I
will try to
prepare a patch set with the first RFC implementation to discuss the API in
more details. Looking forward for your opinions on the matter.
Have you researched what VMWare/Hyper-V/VirtualBox APIs support in this
area ? If they have any existing models, it'd be desirable to look at
them to align our APIs where appropriate.
Also how does this fit in with recent discussions on QEMU mailing list
about enabling 3rd party vendor backup software by having QEMU expose an
NBD server to do efficient sparse backups. That suggested a very different
kind of API where libvirt would not manage the backups, but just provide
an API to allow an NBD target to be enabled for the 3rd party to manage.
Regards,
Daniel
--
|:
http://berrange.com -o-
http://www.flickr.com/photos/dberrange/ :|
|:
http://libvirt.org -o-
http://virt-manager.org :|
|:
http://autobuild.org -o-
http://search.cpan.org/~danberr/ :|
|:
http://entangle-photo.org -o-
http://live.gnome.org/gtk-vnc :|