[libvirt] [RFC PATCH 00/10] introduce push backups

[Martin Kletzander]

On Mon, Nov 14, 2016 at 10:14:52AM +0300, Nikolay Shirokovskiy wrote:
>Push backup is a backup when hypervisor itself copy backup
>data to destination in contrast to pull backup when hypervisor
>exports backup data thru some interface and mgmt itself make
>a copy.
>

This seems interesting.  I'm sorry for bringing this old thread to life
even when it recieved no pings.  Let me know if this is not in your
interests anymore.

>This patch series basically adds API and remote/qemu implementation
> of backup creation and correspondent backup xml description definition.
>

Looks very similar to snapshots from libvirt's POV.  I don't really have
any experience with qemu backups, so this might be a bit stupid
question.  But is the only difference between backup and snapshot the
fact that after backup, the domain still runs on top of the original
file, whereas in snapshots it runs on the new one?

>Just like other blockjobs backup creation is asynchronous. That
>is creation is merely a backup start and client should track
>backup error/completion thru blockjob events. Another option
>is to make backup synchronus operation. AFAIU on this way we
>have to make backup asynchronus job and thus make all modifying
>commands unavailable during backup. This makes backup rather
>obtrusive operation which is not convinient.
>

Sync will block everything, async will block everything excepts query
(by default, you can change the mask of course).  We should be aiming at
async, otherwise you can't even do virDomainJobGetInfo().

>Backup xml desription follows closely snapshot one and
>is described in more details in definition patch [1].
>

You said you didn't use <source/> as snapshots do, but you are thinking
of source/target in the host, however libvirt uses the naming for
host/guest-side representations respectively.  So since the disk is on
host side, <source/> actually makes sense (even though it's, technically
a destination).  How much of snapshot code could we re-use?

Again, sorry for respawning old thread if it's already been obsoleted.

Martin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Digital signature
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20170112/c1c68e81/attachment-0001.sig>