Bug 1232914

The alternative fix for upstream is blockdev-mirror:

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

V2 blockdev-mirror:

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

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

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.

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).

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.

(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.

Sent patches upstream to extend drive_add/del, need to backport them once they
arrive in master. Taking the bug therefore.

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.

Hello guys,

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

Thank you very much,

David Hill

Verification was blocked by bz 1362084.

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.

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!

(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.

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