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