Bug 1412603 - Upload image indicate qcow2 compat 1.1 is unsupported for storage format type V3 in a wrong manner
Summary: Upload image indicate qcow2 compat 1.1 is unsupported for storage format type...
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: ovirt-engine
Classification: oVirt
Component: BLL.Storage
Version: 4.0.5
Hardware: Unspecified
OS: Unspecified
unspecified
medium
Target Milestone: ---
: ---
Assignee: Daniel Erez
QA Contact: Ilanit Stein
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-01-12 12:20 UTC by Ilanit Stein
Modified: 2022-07-01 12:02 UTC (History)
4 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2017-01-25 07:59:37 UTC
oVirt Team: Storage
Embargoed:
sbonazzo: ovirt-4.1-


Attachments (Terms of Use)
screenshot of image_uploader_error (188.79 KB, image/png)
2017-01-12 12:23 UTC, Ilanit Stein
no flags Details


Links
System ID Private Priority Status Summary Last Updated
Red Hat Issue Tracker RHV-46891 0 None None None 2022-07-01 12:02:58 UTC

Description Ilanit Stein 2017-01-12 12:20:28 UTC
Description of problem:
For a compressed qcow2 image, identified by RHV image uploader as:
Format: QCOW2
QCOW2 Compat: 1.1
Size: 1 GB
Backing File: No
Virtual Size: 40 GB

Only if the 'Alias' field is empty, this error is displayed to the user, in the Upload image dialog:
"Uploading an image with qcow2 compat 1.1 is unsupported for storage format type V3"

If the 'Alias' field is filled, and OK is pressed in the Upload image dialog,
the above error will NOT be displayed, 
the image upload will start, ending up in Error event: 	
VDSM <hostname> command failed: Image verification failed: "reason=qcow2 compat u'1.1' not supported by this host"
and the image status is "illegal" (image can't be used)

Version-Release number of selected component (if applicable):
RHV-4.0.5

How reproducible:
100%

Expected results:
Error should be displayed to the user, when trying to upload image in unsupported format, REGARDLESS to the 'Alias' field validation, and it should also BLOCK the upload of such image.

Comment 1 Ilanit Stein 2017-01-12 12:23:10 UTC
Created attachment 1239874 [details]
screenshot of image_uploader_error

Comment 2 Daniel Erez 2017-01-23 11:36:22 UTC
Is it still reproducible in 4.1? I couldn't reproduce it in latest build (using DC 4.0 / SD V3).

Comment 3 Ilanit Stein 2017-01-23 12:16:27 UTC
This bug was reported on RHV-4.0.

On RHV-4.0, 
where the storage domain supported version is V3, 
it is possible to upload file qcow2 V2 (0.10), 
but NOT file qcow2 V3 (1.1) (since storage domain V4 is required).

On RHV-4.1, 
where the storage domain supported version is V4,
it is possible to upload file qcow2 V2 (0.10), 
and file qcow2 V3 (1.1).

Based on the above, this bug is relevant to RHV-4.0, but not to RHV-4.1

Comment 4 Daniel Erez 2017-01-23 12:26:52 UTC
(In reply to Ilanit Stein from comment #3)
> This bug was reported on RHV-4.0.
> 
> On RHV-4.0, 
> where the storage domain supported version is V3, 
> it is possible to upload file qcow2 V2 (0.10), 
> but NOT file qcow2 V3 (1.1) (since storage domain V4 is required).
> 
> On RHV-4.1, 
> where the storage domain supported version is V4,
> it is possible to upload file qcow2 V2 (0.10), 
> and file qcow2 V3 (1.1).
> 
> Based on the above, this bug is relevant to RHV-4.0, but not to RHV-4.1

Thanks Ilanit!
Moving to ON_QA for 4.1.

Comment 5 Raz Tamir 2017-01-23 14:42:52 UTC
Based on comments #3 and #4 moving to verified

Comment 6 Ilanit Stein 2017-01-24 11:30:16 UTC
As I mentioned above, this bug is on RHV-4.0, and should be targeted to fixed on following RHV-4.0 versions.
Based on that, moving bug back to assigned.

Comment 7 Daniel Erez 2017-01-24 12:31:29 UTC
As the target milestone is 4.1 (i.e. we don't want to backport it), it won't be addressed in 4.0. Moving back to ON_QA.


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