Bug 2211608

Summary:	LSM causes discrepancy "Image UUID has a different attribute type on storage(SPARSE) and on DB(PREALLOCATED)"
Product:	Red Hat Enterprise Virtualization Manager	Reporter:	Marian Jankular <mjankula>
Component:	ovirt-engine	Assignee:	Arik <ahadas>
Status:	CLOSED NEXTRELEASE	QA Contact:	Shir Fishbain <sfishbai>
Severity:	medium	Docs Contact:
Priority:	high
Version:	4.5.3	CC:	ahadas, bzlotnik, jortialc, lsurette, michal.skrivanek, srevivo, ycui
Target Milestone:	ovirt-4.5.3-async
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:	If this bug requires documentation, please select an appropriate Doc Type value.	Story Points:	---
Clone Of:		Environment:
Last Closed:	2023-08-03 11:00:24 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 Marian Jankular 2023-06-01 08:30:30 UTC

Description of problem:
when moving a block-based preallocated disk with incremental backup enabled (format: COW, type: PREALLOCATED) to another block-based SD it is moved as (format: COW, type: SPARSE)

Version-Release number of selected component (if applicable):
vdsm-4.50.3.7-1.el8ev.x86_64

How reproducible:
every time

Steps to Reproduce:
1. move block-based preallocated disk with incremental backup enabled (format: COW, type: PREALLOCATED) to another block-based SD

Actual results:
image is - format: COW, type: SPARSE

Expected results:
the image will be - format: COW, type: PREALLOCATED

Additional info:

Comment 6 Arik 2023-07-17 09:17:26 UTC

Benny, you said it sounds familiar, can you please take a quick look?

Comment 7 Casper (RHV QE bot) 2023-07-18 20:30:25 UTC

This bug has low overall severity and is not going to be further verified by QE.

Comment 8 Arik 2023-07-23 06:20:38 UTC

verification steps:
1. create a VM with a disk that is set with incremental-backup enabled a on storage domain
2. start the VM (not mandatory I think but that's part of the reported issue)
3. verify the disk configuration is qcow+preallocated with (on the host that the VM runs on): vdsm-tool dump-volume-chains <storage domain id> | grep -A3 <image id>
4. move the disk to another block storage domain
5. when the disk movement completes, verify the disk configuration remains qcow+preallocated with the aforementioned command in step 3 (that points to the new storage domain)

Comment 11 Casper (RHV QE bot) 2023-08-03 11:00:24 UTC

This bug has low overall severity and passed an automated regression suite, and is not going to be further verified by QE.