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?
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.
Maxim
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list