Bug 1298231

Summary:	Allocation policy of new disk doesn't follow Optimized for field
Product:	[oVirt] ovirt-engine	Reporter:	jniederm
Component:	Frontend.WebAdmin	Assignee:	Tomas Jelinek <tjelinek>
Status:	CLOSED NOTABUG	QA Contact:	Pavel Stehlik <pstehlik>
Severity:	medium	Docs Contact:
Priority:	high
Version:	3.6.3	CC:	amureini, bugs, derez, mgoldboi, michal.skrivanek, tnisan, ylavi
Target Milestone:	ovirt-3.6.5	Flags:	michal.skrivanek: ovirt-3.6.z? rule-engine: planning_ack? michal.skrivanek: devel_ack+ rule-engine: testing_ack?
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2016-03-07 12:15:10 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	Virt	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description jniederm 2016-01-13 14:53:04 UTC

Description of problem:
Resource allocation > Storage Allocation > 'Template provisioning' follows 'Optimized for' field in New VM dialog (Desktop -> Thin, Server -> Clone). 'Allocation policy' option in 'New Virtual Disk' dialog (opened by General > Instance images > Create in New VM dialog) should behave similarly.

Version-Release number of selected component (if applicable):
3.6.3 master, commit a96d7ea

How reproducible:
100%

Steps to Reproduce:
1. In Webadmin:
2. Open New VM dialog
3. Set 'Optimized for' to 'Server'
4. Click General > Instance images > Create button to open New Virtual Disk dialog

Actual results:
Allocation policy is 'Thin provisioning'

Expected results:
Allocation policy follows 'Optimized for':
Desktop -> Thin Provision
Server -> Preallocated

Comment 1 Red Hat Bugzilla Rules Engine 2016-01-13 14:56:23 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 2 Tomas Jelinek 2016-02-18 11:18:15 UTC

@Daniel: this bug wants to unify the provisioning of the VM disks created from template with the ones created directly. 

The problem is that:
- the disks taken from template are thin if VM type is desktop and clone if vm type is server. 
- the disks created as new are: getVolumeType().setSelectedItem(storageType.isBlockDomain() ? VolumeType.Preallocated : VolumeType.Sparse);

Is there any reason why is this based on the storage type? Would it be ok if it would be based on the VM type and only if the VM is not present it would be according to the storage type?

BTW we are talking about defaults here the user can change anyway...

Comment 3 Daniel Erez 2016-02-29 13:36:26 UTC

(In reply to Tomas Jelinek from comment #2)
> @Daniel: this bug wants to unify the provisioning of the VM disks created
> from template with the ones created directly. 
> 
> The problem is that:
> - the disks taken from template are thin if VM type is desktop and clone if
> vm type is server. 
> - the disks created as new are:
> getVolumeType().setSelectedItem(storageType.isBlockDomain() ?
> VolumeType.Preallocated : VolumeType.Sparse);
> 
> Is there any reason why is this based on the storage type? Would it be ok if
> it would be based on the VM type and only if the VM is not present it would
> be according to the storage type?

The default for block domain is preallocated as raw format is not applicable for sparse in block domains (and we create a new disk as raw). Sparse in block domains is implemented by extending the lv by 1 GB increments as needed (less efficient..)

> 
> BTW we are talking about defaults here the user can change anyway...

I think we should keep the current default when creating a new disk, though not sure regarding the New VM dialog. I guess it's just a question of consistency.
@Yaniv - what do you think?

Comment 4 Tomas Jelinek 2016-03-07 08:58:04 UTC

@Moran, what you think?

Comment 5 Yaniv Lavi 2016-03-07 11:50:13 UTC

(In reply to Daniel Erez from comment #3)
> (In reply to Tomas Jelinek from comment #2)
> > @Daniel: this bug wants to unify the provisioning of the VM disks created
> > from template with the ones created directly. 
> > 
> > The problem is that:
> > - the disks taken from template are thin if VM type is desktop and clone if
> > vm type is server. 
> > - the disks created as new are:
> > getVolumeType().setSelectedItem(storageType.isBlockDomain() ?
> > VolumeType.Preallocated : VolumeType.Sparse);
> > 
> > Is there any reason why is this based on the storage type? Would it be ok if
> > it would be based on the VM type and only if the VM is not present it would
> > be according to the storage type?
> 
> The default for block domain is preallocated as raw format is not applicable
> for sparse in block domains (and we create a new disk as raw). Sparse in
> block domains is implemented by extending the lv by 1 GB increments as
> needed (less efficient..)
> 
> > 
> > BTW we are talking about defaults here the user can change anyway...
> 
> I think we should keep the current default when creating a new disk, though
> not sure regarding the New VM dialog. I guess it's just a question of
> consistency.
> @Yaniv - what do you think?

We should keep the current default since performance on sparse block storage is a unneeded overhead.

Comment 6 Tomas Jelinek 2016-03-07 12:15:10 UTC

The default for the new disk is based on the storage type for performance reasons.
The default for template disk provisioning is based on the VM type.
Works as intended, closing as not a bug.