'qemu-img convert' performance regression when target is a LVM volume

[Fridtjof Mund]

Running Ubuntu Server 18.04 with the Ubuntu Cloud Archive repository on release 'bionic-updates/stein'

qemu-utils version 1:3.1+dfsg-2ubuntu3.7~cloud0

With bionic-updates/rocky and (stock bionic-updates) qemu-utils version 1:2.11+dfsg-1ubuntu7.31, the following command takes ~35 seconds to complete:

# qemu-img convert -p -O raw -t none -f qcow2 some-qcow2.img /dev/mapper/cinder--volumes-volume--9d18daa7--691c--44bc--b4c8--a60cc70a435d

With bionic-updates/stein and qemu-utils version 1:3.1+dfsg-2ubuntu3.7~cloud0, the same command does not progress visibly (-p displays a rough percentage done), still displaying 0% finished after two minutes.

Basic package level bisecting shows that qemu-utils version 1:4.0+dfsg-0ubuntu9.8~cloud0 (from bionic-updates/train) fixes the regression, behaving like 1:2.11+dfsg-1ubuntu7.31 again.

After verifying the bug also exists upstream, I bisected with the following results:

- The bug was introduced with commit 34fa110e424e9a6a9b7e0274c3d4bfee766eb7ed (between v3.0.0-rc2 and rc3)

- The bug was fixed with commit c9fdcf202f19fc2acdcb1ee0522ff5d61bf8c906 (between v3.1 and v4.0), which is part of this patchset: https://patchwork.kernel.org/cover/10865751/

[Christian Ehrhardt  (paelzer)]

Thank you Fridtjof, for active Ubuntu releases this is either not present or fixed already:
 qemu | 1:2.5+dfsg-5ubuntu10.45 | xenial-updates | source
 qemu | 1:2.11+dfsg-1ubuntu7.31 | bionic-updates | source
 qemu | 1:4.2-3ubuntu6.4 | focal-updates | source, amd64, arm64, armhf, ppc64el, riscv64, s390x

3.1 was based on Ubuntu Disco (19.04) - But you are right it is present in Stein still, let me help you to re-target the bug accordingly for the Openstack Team to see it.