Bug 1324006

Summary:	RFE: storage: don't use qemu-img convert if cloning volume without format conversion, just us cp method
Product:	[Community] Virtualization Tools	Reporter:	James Hogarth <james.hogarth>
Component:	libvirt	Assignee:	Libvirt Maintainers <libvirt-maint>
Status:	CLOSED DEFERRED	QA Contact:
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	unspecified	CC:	agedosier, berrange, clalancette, crobinso, imz, itamar, jforbes, laine, libvirt-maint, redhat, veillard, virt-maint, yehuda
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2021-08-18 13:57:44 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description James Hogarth 2016-04-05 10:34:48 UTC

Description of problem:
Attempting to use --reflink with a btrfs based directory fails if the guest image is of the qcow2 format but works if it's raw format. Give these are just files I'd have expected it to work for either and qcow2 brings certain benefits over raw of course.

Version-Release number of selected component (if applicable):
libvirt-client-1.2.18.2-3.fc23.x86_64
qemu-img-2.4.1-8.fc23.x86_64


How reproducible:
Every time

Steps to Reproduce:
0. Have a reflink capable filesystem such as btrfs for the pool
1. virsh -d0 vol-create-as  default example.qcow2 20G --format qcow2
2. virsh -d0 vol-clone  --pool default example.qcow2 example2.qcow2 --reflink
3. virsh -d0 vol-clone  --pool default example.qcow2 example3.qcow2
4. virsh -d0 vol-create-as  default example.raw 20G --format raw
5. virsh -d0 vol-clone  --pool default example.raw example2.raw --reflink
6. virsh -d0 vol-clone  --pool default example.raw example3.raw 


Actual results:
The qcow2 reflink clone fails with:
vol-clone: pool(optdata): default
vol-clone: vol(optdata): example.qcow2
vol-clone: newname(optdata): example2.qcow2
vol-clone: reflink(bool): (none)
vol-clone: found option <pool>: default
vol-clone: <pool> trying as pool NAME
vol-clone: found option <vol>: example.qcow2
vol-clone: <vol> trying as vol name
error: Failed to clone vol from example.qcow2
error: unsupported flags (0x2) in function virStorageBackendCreateQemuImg


Expected results:
It should complete the reflink clone the same as a raw file does:
vol-clone: pool(optdata): default
vol-clone: vol(optdata): example.raw
vol-clone: newname(optdata): example2.raw
vol-clone: reflink(bool): (none)
vol-clone: found option <pool>: default
vol-clone: <pool> trying as pool NAME
vol-clone: found option <vol>: example.raw
vol-clone: <vol> trying as vol name
Vol example2.raw cloned from example.raw


Additional info:
Doing a non-reflink clone works and cp --reflink=always for the given file of course works as it's not a filesystem issue but something up with virStorageBackendCreateQemuImg, which of course is not hit for a raw image.

Comment 1 Cole Robinson 2016-04-11 23:22:19 UTC

Libvirt invokes 'qemu-img convert' for any non-raw format, which doesn't know anything about reflink, hence the error. That's to support duplicating a volume into a different format. But we can probably just use the plain cp method if both formats match. It needs to be investigated though if qemu-img convert is giving us other semantics that we can't drop

Comment 2 Daniel Berrangé 2021-08-18 13:57:44 UTC

(In reply to Cole Robinson from comment #1)
> Libvirt invokes 'qemu-img convert' for any non-raw format, which doesn't
> know anything about reflink, hence the error. That's to support duplicating
> a volume into a different format. But we can probably just use the plain cp
> method if both formats match. It needs to be investigated though if qemu-img
> convert is giving us other semantics that we can't drop

It is common to use "qemu-img convert" to get a clean qcow2 image

 - Ensures it is using the latest qcow2 features
 - Reduces space consumed if the clusters in the original image were no longer holding guest data and TRIM wasn't used
 - Reduces space consumed if internal snapshots were deleted

Given the age of this bug it doesn't seem likely that anyone will implement  support for reflink with non-raw formats in the forseeable future and keeping this bug open won't change that.