More recent references: http://comments.gmane.org/gmane.comp.emulators.qemu/303834 https://github.com/qemu/qemu/blob/master/docs/bitmaps.md (notice the libvirt API/design is still a work in progress) +++ This bug was initially created as a clone of Bug #1207659 +++ +++ This bug was initially created as a clone of Bug #1207657 +++ QEMU is getting incremental live backup, where a dirty block bitmap is available to third-party applications so they can read only blocks that changed since the previous backup. Upstream references: http://lists.gnu.org/archive/html/qemu-devel/2015-03/msg04501.html http://lists.gnu.org/archive/html/qemu-devel/2015-03/msg05796.html
if I'm not mistaken this is http://wiki.qemu.org/Features/Livebackup flagging storage
(In reply to Michal Skrivanek from comment #1) > if I'm not mistaken this is http://wiki.qemu.org/Features/Livebackup Unfortunately not. The wiki above is very outdated, from a previous try at live-backup. Updating the wiki is in our to-do list. > flagging storage storage indeed, thanks.
(In reply to Ademar Reis from comment #2) > (In reply to Michal Skrivanek from comment #1) > > if I'm not mistaken this is http://wiki.qemu.org/Features/Livebackup > > Unfortunately not. The wiki above is very outdated, from a previous try at > live-backup. Updating the wiki is in our to-do list. > http://wiki.qemu.org/Features/IncrementalBackup (thanks to John Snow)
*** Bug 1608452 has been marked as a duplicate of this bug. ***
This bug has not been marked as blocker for oVirt 4.3.0. Since we are releasing it tomorrow, January 29th, this bug has been re-targeted to 4.3.1.
Hi Daniel, In order to qa_ack this but I need to know if we(QE) have the capacity meaning I need to know: 1) The basic scenario/s (go/ no go flows) of how to test this feature. 2) Do we have a build (downstream 4.3/4.4 complete build not integration mode) to test the basic scenario on? 3) Are all API's (libvirt) available? I see this bug is dependant on bug 1734975 and bug 1734976 which are in NEW state.
(In reply to Avihai from comment #8) > Hi Daniel, > > In order to qa_ack this but I need to know if we(QE) have the capacity > meaning I need to know: > > 1) The basic scenario/s (go/ no go flows) of how to test this feature. > > 2) Do we have a build (downstream 4.3/4.4 complete build not integration > mode) to test the basic scenario on? > > 3) Are all API's (libvirt) available? > I see this bug is dependant on bug 1734975 and bug 1734976 which are in NEW > state. I see all dependant bugs are verified so disregard this question. Questions 1) and 2) are still relevant for 4.4. As the responsibility for this feature changed to Eyal, I'm changing NEEDINFO accordingly. Please also change the assignee for this bug.
(In reply to Avihai from comment #8) > Hi Daniel, > > In order to qa_ack this but I need to know if we(QE) have the capacity > meaning I need to know: > > 1) The basic scenario/s (go/ no go flows) of how to test this feature. Please use - https://ovirt.org/develop/release-management/features/storage/incremental-backup.html > > 2) Do we have a build (downstream 4.3/4.4 complete build not integration > mode) to test the basic scenario on? Yes, already available in the latest beta of 4.4
Moved to 4.4.1 not being marked as blocker for 4.4.0 and we are preparing to GA.
> Incremental backup flow: > > 1. The customer has a VM with disks and wants to create a backup for it. > 2. The customer can now create a full backup for the VM disks using a new > backup API while the VM is running. > 3. When the backup is done, the customer can download the backup disks using > a new API provided by imageIO. > 4. The customer continue to work with the VM and new data is written to the > disk. > 5. The customer need to perform a new backup that includes the new data. > 6. The customer can now create an incremental backup for the VM disks using > a new backup API while the VM is running, > this backup will include only the blocks that changed on the disks. > 8. When the backup is done, the customer can download the incremental backup > disks using a new API provided by imageIO, > the downloaded disks will include only the data that changed in the time > between the first > full backup until the beginning of the incremental backup. This case is covered by the following TC's: TestCase27284 This is sanity test for Restoring from full backup and checking the content TestCase27165 This is sanity test for Restoring from incremental backup and checking the content. Both case (and others which were tested as well) are described in the 'incremental backup test plan" here: https://polarion.engineering.redhat.com/polarion/#/project/RHEVM3/wiki/Storage_4_0/4_4_Storage_Incremental_Backup Verified on rhv-release-4.4.1-3-001.noarch
This bugzilla is included in oVirt 4.4.1 release, published on July 8th 2020. Since the problem described in this bug report should be resolved in oVirt 4.4.1 release, it has been closed with a resolution of CURRENT RELEASE. If the solution does not work for you, please open a new bug report.