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

[Nikolay Shirokovskiy]

By the way we came to agreement to create distinct API to support backup operations in [1]
and there is a discussion of pull backup series in [2]. The latter is blocked
as some necessary operations are still experimental in qemu.

[1] https://www.redhat.com/archives/libvir-list/2016-March/msg00937.html
[2] https://www.redhat.com/archives/libvir-list/2016-September/msg00192.html

On 18.01.2017 12:18, Nikolay Shirokovskiy wrote:
> 
> 
> On 12.01.2017 16:16, Martin Kletzander wrote:
>> 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.
> 
> It is not that old ))) and I has been looking forward for a review all this
> time. So I hope your response brings more attention.
> 
>>
>>> 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?
> 
> The mechanics is quite different from snapshot one too. Disk only snapshot
> is basically a creation of new disk image file with old one as backing
> file and switching running qemu process to the new image, it takes very
> little time generally. 
> 
> Backup on the other hand is lenghy process. Qemu keeps running on the
> same image but creates kind of inverse in memory snapshot to keep 
> disk state at the moment of backup start. This disk state is written
> to disk as backup.
> 
>>
>>> 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().
>>
> 
> Well good point, but then you can not use virDomainSetMemoryFlags
> (QEMU_JOB_MODIFY job) on a domain running backup for example. This
> can be inconvinient as backup expected to be rather transparent. On
> the other hand job types can be revised to allow modifications to
> domain running a backup.
> 
>>> 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
> 
> ok, i'll use <source>
> 
>> a destination).  How much of snapshot code could we re-use?
> 
> Well I read the snapshot code to some extent to find out similar
> cases like disks labeling etc. From my POV in general there is
> no much common for snapshot and backup code. Parts that can 
> be reused are sparse and need extra preparation so I would
> not put this work in this patch series.
> 
> Nikolay
> 
> --
> libvir-list mailing list
> libvir-list at redhat.com
> https://www.redhat.com/mailman/listinfo/libvir-list
>