Am 22.02.2017 um 22:17 schrieb John Snow:
On 02/22/2017 03:45 AM, Peter Lieven wrote:
Am 21.02.2017 um 22:13 schrieb John Snow:
On 02/21/2017 07:43 AM, Peter Lieven wrote:
Hi,
is there anyone ever thought about implementing something like VMware
CBT in Qemu?
https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1020128
Thanks,
Peter
A bit outdated now, but:
http://wiki.qemu-project.org/Features/IncrementalBackup
and also a summary I wrote not too far back (PDF):
https://drive.google.com/file/d/0B3CFr1TuHydWalVJaEdPaE5PbFE
and I'm sure the Virtuozzo developers could chime in on this subject,
but basically we do have something similar in the works, as eblake says.
Hi John, Hi Erik,
thanks for your feedback. Are you both the ones working primary on this topic?
If there is anything to review or help needed, please let me know.
I've been working on incremental backups; Fam and I now co-maintain
block/dirty-bitmap.c.
Vladimir Sementsov-Ogievskiy has been working on bitmap persistence and
migration from Virtuozzo; as well as the NBD specification amendment to
allow us to fleece images with dirty bitmaps.
(Check the wiki and the whitepaper I linked!)
Eric has been guiding the review process for the NBD side of things.
My 2 cents:
I thing I had in mind if there is no image fleecing available, but fetching the
dirty bitmap
from external would be a feauture to put a write lock on a block device.
Write lock means, drain all pending writes and queue all further writes until
unlock (as if they
were throttled to zero). This could help fetch consistent backups from storage
device (thinking of iSCSI SAN) without
the help of the hypervisor to actually transfer data (no load in the frontend
network or the host). What would further
be needed is a write generation for each block, not just only a dirty bitmap.
In this case something like this via QMP (and external software) should work:
---8<---
gen = write generation of last backup (or 0 for full backup)
do {
nextgen = fetch current write generation (via QMP)
As Eric said, there's a lot of hostility to using QMP as a metadata
transmission protocol.
dirtymap = send all block whose write generation is greater than 'gen'
(via QMP)
dirtycnt = 0
foreach block in dirtymap {
copy to backup via external software
dirtycnt++
}
gen = nextgen
} while (dirtycnt < X) <--- to achieve this a thorttling or similar
might be needed
fsfreeze (optional)
write lock (via QMP)
backupgen = fetch current write generation (via QMP)
dirtymap = send all block whose write generation is greater than 'gen' (via QMP)
foreach block in dirtymap {
copy to backup via external software
}
unlock (via QMP)
fsthaw (optional)
--->8---
As far as I understand CBT in VMware is not just only a dirty bitmap, but also
a write generation tracking for blocks (size 64kb or whatever)
I think at the moment I'm worried about getting the basic features out
the door, but I'm not opposed to adding fancier features if there's
justification or demand for them.
Sure, the basic features are most important. I was just thinking of the above scenario to
interact with a NAS and have Qemu's "help"
to create incremental backups.
Peter
