This service will be undergoing maintenance at 00:00 UTC, 2017-10-23 It is expected to last about 30 minutes
Bug 1298231 - Allocation policy of new disk doesn't follow Optimized for field
Allocation policy of new disk doesn't follow Optimized for field
Status: CLOSED NOTABUG
Product: ovirt-engine
Classification: oVirt
Component: Frontend.WebAdmin (Show other bugs)
3.6.3
Unspecified Unspecified
high Severity medium (vote)
: ovirt-3.6.5
: ---
Assigned To: Tomas Jelinek
Pavel Stehlik
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2016-01-13 09:53 EST by jniederm
Modified: 2016-03-07 07:15 EST (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-03-07 07:15:10 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: Virt
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
michal.skrivanek: ovirt‑3.6.z?
rule-engine: planning_ack?
michal.skrivanek: devel_ack+
rule-engine: testing_ack?


Attachments (Terms of Use)

  None (edit)
Description jniederm 2016-01-13 09:53:04 EST
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 09:56:23 EST
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 06:18:15 EST
@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 08:36:26 EST
(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 03:58:04 EST
@Moran, what you think?
Comment 5 Yaniv Lavi (Dary) 2016-03-07 06:50:13 EST
(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 07:15:10 EST
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.

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