Bug 1100999 - When a template is located on 2 domains and allocation policy has mixed types, UI reports wrongly,"thin provision template".
Summary: When a template is located on 2 domains and allocation policy has mixed types...
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: ovirt-engine
Classification: oVirt
Component: General
Version: ---
Hardware: Unspecified
OS: Unspecified
unspecified
medium
Target Milestone: ---
: ---
Assignee: Tal Nisan
QA Contact: Raz Tamir
URL:
Whiteboard:
Depends On: ovirt_refactor_disk_class_hierarchy
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-05-25 09:20 UTC by Ori Gofen
Modified: 2022-05-16 07:45 UTC (History)
11 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-09-03 09:19:26 UTC
oVirt Team: Storage
Embargoed:
sbonazzo: ovirt-4.2-


Attachments (Terms of Use)
wrong_disk_format (32.16 KB, image/jpeg)
2014-05-28 12:49 UTC, Daniel Erez
no flags Details


Links
System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 1403183 0 high CLOSED Cloned VMs created from template with "Raw" format are having "Thin Provision" Allocation Policy 2021-09-09 12:07:51 UTC
Red Hat Issue Tracker RHV-46042 0 None None None 2022-05-16 07:45:57 UTC

Internal Links: 1403183

Description Ori Gofen 2014-05-25 09:20:48 UTC
Description of problem:

When copying a thin provision nfs template to iscsi domain,the image group that is created on the block domain consists of one raw preallocated volume disk.
on NFS domain the template consists of raw sparse logical volume.

from terminal vdsClient:

on NFS->

[root@camel-vdsb data-center]# vdsClient -s 0 getVolumeInfo $sduuid $spuuid $imuuid `vdsClient -s 0 getVolumesList $sduuid $spuuid $imuuid`
	status = OK
	domain = 1b2dcee9-bcb1-4b80-8e7f-eaa4fc659c1a
	capacity = 4294967296
	voltype = SHARED
	description = Active VM
	parent = 00000000-0000-0000-0000-000000000000
	format = RAW
	image = 4158dea2-9c92-4167-a65f-bde633364745
	uuid = ab488d9f-fa43-4b67-bb1a-7e0405c3e652
	disktype = 2
	legality = LEGAL
	mtime = 1401007275
	apparentsize = 4294967296
	truesize = 24576
	type = SPARSE
	children = []
	pool = 
	ctime = 1401007275

on ISCSI->

[root@camel-vdsb data-center]# vdsClient -s 0 getVolumeInfo $sduuid $spuuid $imuuid `vdsClient -s 0 getVolumesList $sduuid $spuuid $imuuid`
	status = OK
	domain = ceb80915-8207-4ebe-9c45-458676fdf223
	capacity = 4294967296
	voltype = SHARED
	description = 
	parent = 00000000-0000-0000-0000-000000000000
	format = RAW
	image = 4158dea2-9c92-4167-a65f-bde633364745
	uuid = ab488d9f-fa43-4b67-bb1a-7e0405c3e652
	disktype = 2
	legality = LEGAL
	mtime = 1401007365
	apparentsize = 4294967296
	truesize = 4294967296
	type = PREALLOCATED
	children = []
	pool = 
	ctime = 1401007363


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

vdsm-4.14.7-3.el6ev.x86_64
rhevm-3.4.0-0.21.el6ev.noarch

How reproducible:
100%

Steps to Reproduce:
Setup:have a shared dc with two domains(one nfs,one iscsi)

1.create vm+thin nfs disk-> create a template from this disk
2.copy template to iscsi domain

Actual results:
the web admin ui reports of a thin provision template(see image)

Expected results:
we should see both,or whatever makes sense

Additional info:

Comment 1 Daniel Erez 2014-05-28 12:49:26 UTC
Created attachment 899967 [details]
wrong_disk_format

Comment 2 Allon Mureinik 2014-07-30 13:42:28 UTC
Currently, the storage properties are coupled to the disk entity, even if it has two different physical copies.

In 3.6 we should refactor the disk BE to separate the logical properties from the storage ones.
Tal - please make sure this RFE is filed.

Comment 3 Allon Mureinik 2015-01-26 08:16:18 UTC
(In reply to Allon Mureinik from comment #2)
> Currently, the storage properties are coupled to the disk entity, even if it
> has two different physical copies.
> 
> In 3.6 we should refactor the disk BE to separate the logical properties
> from the storage ones.
> Tal - please make sure this RFE is filed.

This is bug 1142762.

Comment 4 Red Hat Bugzilla Rules Engine 2015-11-30 19:03:05 UTC
Target release should be placed once a package build is known to fix a issue. Since this bug is not modified, the target version has been reset. Please use target milestone to plan a fix for a oVirt release.

Comment 5 Sandro Bonazzola 2016-05-02 09:56:57 UTC
Moving from 4.0 alpha to 4.0 beta since 4.0 alpha has been already released and bug is not ON_QA.

Comment 6 Yaniv Lavi 2016-05-23 13:18:13 UTC
oVirt 4.0 beta has been released, moving to RC milestone.

Comment 7 Yaniv Lavi 2016-05-23 13:25:02 UTC
oVirt 4.0 beta has been released, moving to RC milestone.

Comment 9 Allon Mureinik 2017-09-03 09:19:26 UTC
Frankly. I don't see us ever getting to this. Closing.

If anyone thinks this is important, please explain why and reopen.


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