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