Bug 905123 - QEMU offline mirror support (using a persistent dirty bitmap)
QEMU offline mirror support (using a persistent dirty bitmap)
Status: NEW
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: qemu-kvm-rhev (Show other bugs)
7.0
Unspecified Unspecified
medium Severity medium
: rc
: ---
Assigned To: John Snow
Qianqian Zhu
: FutureFeature
Depends On:
Blocks: 1207657 883504
  Show dependency treegraph
 
Reported: 2013-01-28 11:19 EST by Paolo Bonzini
Modified: 2018-01-01 20:18 EST (History)
11 users (show)

See Also:
Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed:
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Paolo Bonzini 2013-01-28 11:19:07 EST
When issuing the drive-mirror command for storage migration, you must restart the process from scratch if one of the following things happen: 1) QEMU crashes; 2) the VM is exited before QEMU is ready to pivot to the destination storage (before QEMU has reached "steady state").

This can be handled with a persistent dirty bitmap.  A new instance of QEMU, or a new qemu-img command can then be used to complete storage migration.
Comment 3 John Snow 2015-06-25 14:36:12 EDT
Will not land in QEMU 2.4 and thus will not land in RHEL 7.2. Actively being worked on upstream, Expected for 2.5.
Comment 5 John Snow 2017-04-27 16:14:16 EDT
Still pending upstream as of 2.10 development window and will not be ready in time for proper testing in 7.4, unfortunately.

Bitmap persistence itself is a work in progress, but there are currently no discussions or plans for how precisely to implement offline storage migration, but it will happen almost certainly after persistence itself is completed.

I'll refrain from giving estimates... but please see upstream feature pages for updates: http://wiki.qemu.org/Features/IncrementalBackup
Comment 6 John Snow 2017-11-16 17:25:59 EST
Bitmap persistence has been checked in upstream.

The RFE here, "finishing bitmap storage offline" needs to be planned and implemented, but should now be possible to do.

Regardless, this is not 7.5 material. If anyone has a pressing use case where this would be critical to elevate the importance of, let me know. Treating it as "wish list" otherwise.
Comment 7 John Snow 2017-12-05 17:36:48 EST
The last blocks (1518989) is not quite strictly true, depends on what we want this BZ to be for; the title is two things:

(1) Persistent bitmap support (done and upstream)
(2) Offline mirror/migration support -- this is RFE.

The "blocks" semantic there does not apply to (2) but only (1).

Propose updating topic to refer specifically to offline mirror support and removing the blocks: dep, shifting this BZ to purely RFE, and letting 1518989 cover the persistence case.
Comment 8 Ademar Reis 2017-12-08 07:45:30 EST
(In reply to John Snow from comment #7)
> The last blocks (1518989) is not quite strictly true, depends on what we
> want this BZ to be for; the title is two things:
> 
> (1) Persistent bitmap support (done and upstream)
> (2) Offline mirror/migration support -- this is RFE.
> 
> The "blocks" semantic there does not apply to (2) but only (1).
> 
> Propose updating topic to refer specifically to offline mirror support and
> removing the blocks: dep, shifting this BZ to purely RFE, and letting
> 1518989 cover the persistence case.

Done.

Note You need to log in before you can comment on or make changes to this bug.