Bug 1232914 - preserve sparseness for drive mirror operations over distributed storage - qemu
Summary: preserve sparseness for drive mirror operations over distributed storage - qemu
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: qemu-kvm-rhev
Version: 7.1
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: rc
: 7.2
Assignee: Kevin Wolf
QA Contact: Qianqian Zhu
URL:
Whiteboard:
Depends On: 1242316
Blocks: 1229843 1288337 1297255 1298106
TreeView+ depends on / blocked
 
Reported: 2015-06-17 19:46 UTC by Pádraig Brady
Modified: 2017-02-06 18:11 UTC (History)
25 users (show)

Fixed In Version: QEMU 2.6
Doc Type: Bug Fix
Doc Text:
Clone Of:
: 1297255 1298106 (view as bug list)
Environment:
Last Closed: 2016-11-07 20:24:14 UTC
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Knowledge Base (Solution) 2022583 None None None 2017-01-26 06:56:26 UTC
Red Hat Product Errata RHBA-2016:2673 normal SHIPPED_LIVE qemu-kvm-rhev bug fix and enhancement update 2016-11-08 01:06:13 UTC

Description Pádraig Brady 2015-06-17 19:46:34 UTC
As originally discussed in bug #1221468 this is to track
backporting of this feature to RHEL 7.2

A proposed upstream patch is at:
https://patchwork.ozlabs.org/patch/481797/

Ideally this would support both RBD and NFS

Comment 1 Fam Zheng 2015-06-23 04:25:22 UTC
The alternative fix for upstream is blockdev-mirror:

http://lists.nongnu.org/archive/html/qemu-block/2015-06/msg00292.html

Comment 5 Pádraig Brady 2015-07-08 12:26:46 UTC
V2 blockdev-mirror:

https://lists.gnu.org/archive/html/qemu-devel/2015-06/msg06560.html

Comment 6 Pádraig Brady 2015-07-10 14:16:09 UTC
http://git.qemu.org/?p=qemu.git;a=commitdiff;h=v2.3.0-1612-g0fc9f8e is scheduled to be backported next week to address this

Comment 11 Fam Zheng 2015-09-06 08:58:30 UTC
I'm sorry for the delay. Neither solution made into upstream 2.4 release and are still being worked on. I propose we fix this in 7.3 once upstream patches have settled and backport to z-stream as necessary.

Comment 14 Fam Zheng 2016-01-11 01:27:23 UTC
The solution provided by QEMU is using the new "blockdev-add" + "blockdev-mirror" commands, which will be ready in upstream 2.6 and therefore included in RHEL 7.3 (more precisely, equivalent RHEV versions).

Comment 21 Peter Krempa 2016-02-04 16:45:36 UTC
I've discussed the matter with Kevin and we've concluded the following:
- blockdev-add should not yet be used by libvirt, the interface isn't ready yet
- drive_add is a option, but it needs tweaking to allow adding a image without a backend
- drive_del needs to be able to delete such image (x-blockdev-del isn't an option upstream)

Additionally libvirt needs to add flags to the public API that will enable the "detect_zeroes" feature on demand.

I'm moving this back to ASSIGNED since the interface wouldn't work at this point.

Comment 22 Ademar Reis 2016-02-17 14:04:46 UTC
(In reply to Peter Krempa from comment #21)
> I'm moving this back to ASSIGNED since the interface wouldn't work at this
> point.

You forgot to move it back to ASSIGNED. Doing it now.

Comment 23 Kevin Wolf 2016-02-26 13:09:29 UTC
Sent patches upstream to extend drive_add/del, need to backport them once they
arrive in master. Taking the bug therefore.

Comment 24 Ademar Reis 2016-02-26 17:54:14 UTC
We closed the z-stream clone as WONTFIX because the fix is too intrusive for the z-stream, specially from libvirt point of view. Removing ZStream keyword.

Comment 26 David Hill 2016-07-31 15:26:33 UTC
Hello guys,

   This has been in this state for ~ 2 months...  Is it still being worked on?

Thank you very much,

David Hill

Comment 27 Qianqian Zhu 2016-08-01 09:38:59 UTC
Verification was blocked by bz 1362084.

Comment 28 Qianqian Zhu 2016-08-03 10:14:42 UTC
Test with:
qemu-kvm-rhev-2.6.0-17.el7.x86_64
qemu-img-rhev-2.6.0-17.el7.x86_64
kernel-3.10.0-475.el7.x86_64

Steps:
1. launch guest with:
/usr/libexec/qemu-kvm -drive file=/nfs/win10-64-virtio-scsi.qcow2,if=none,cache=writeback,id=drive-virtio-blk0,format=qcow2 -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x7,drive=drive-virtio-blk0,id=virtio-disk0 -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x6 -monitor stdio -qmp tcp:0:5555,server,nowait

2. Zeroed out first 10k data:
qemu-io drive-virtio-blk0 "write -P 0 0 10k"

3. Check source image with qemu-img map:
# qemu-img map --output=json /mntnfs/win10-64-virtio-scsi.qcow2 |head -n 3
[{ "start": 0, "length": 65536, "depth": 0, "zero": false, "data": true, "offset": 327680},
{ "start": 65536, "length": 983040, "depth": 0, "zero": true, "data": false},
{ "start": 1048576, "length": 65536, "depth": 0, "zero": false, "data": true, "offset": 393216},

4. Add drive with detect-zeroes=on
drive_add -n 0 file.filename=/nfs/mirror_on.qcow2,node-name=d1,detect-zeroes=on

5. blockdev-mirror to added drive:
 {"execute":"blockdev-mirror", "arguments": { "device": "drive-virtio-blk0", "target": "d1", "sync":"full"}}

6. Check the first 10k data marked as "zero":true
# qemu-img map --output=json /nfs/mirror_on.qcow2 |head -n 3

Result:
[{ "start": 0, "length": 1048576, "depth": 0, "zero": true, "data": false},
{ "start": 1048576, "length": 65536, "depth": 0, "zero": false, "data": true, "offset": 458752},
{ "start": 1114112, "length": 65536, "depth": 0, "zero": false, "data": true, "offset": 393216},

Compare qemu-img map result with same steps but detect-zero=off:
[{ "start": 0, "length": 65536, "depth": 0, "zero": false, "data": true, "offset": 589824},
{ "start": 65536, "length": 983040, "depth": 0, "zero": true, "data": false},
{ "start": 1048576, "length": 65536, "depth": 0, "zero": false, "data": true, "offset": 524288},

The result tells that zeroed data was kept zero after mirroring with detect-zeroes=on.

Fam, do you think the above result was able to verify this bz enough? Thanks.

Comment 29 Fam Zheng 2016-08-04 01:22:41 UTC
Yes, I think it is correct.

One minor thing is, using qemu-img map on the source/target, while they are still used by the guest, is not quite safe (the output might be bogus, because of unflushed cache, etc.). But they happen to match the expectation here, so probably not a big problem.

Thanks for your effort!

Comment 30 Qianqian Zhu 2016-08-04 01:41:25 UTC
(In reply to Fam Zheng from comment #29)
> Yes, I think it is correct.
> 
> One minor thing is, using qemu-img map on the source/target, while they are
> still used by the guest, is not quite safe (the output might be bogus,
> because of unflushed cache, etc.). But they happen to match the expectation
> here, so probably not a big problem.
> 
> Thanks for your effort!

Thanks Fam for your confirmation and detailed explanation.
I will move this bug to verified base on comment 28 and comment 29, and remove the dependence on bz 1362084.

Comment 32 errata-xmlrpc 2016-11-07 20:24:14 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHBA-2016-2673.html


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