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
