Red Hat Bugzilla – Bug 1178021
RHEV: Faulty storage allocation checks when adding a VM Pool with VMs.
Last modified: 2016-02-10 11:40:45 EST
+++ This bug was initially created as a clone of Bug #1143888 +++ AddVmPoolWithVmsCommand - VMs in the pool are added with empty disks (Thinly provisioned from the template). There are no memory volumes not snapshots. Storage allocation validation should be applied - StorageDomainValidator.HadSpaceForNewDisks(). Current validation is using old deprecated code. Verification of this bug should follow the following table: | File Domain | Block Domain -----|-----------------------------------------|------------- qcow | 1M (header size) | 1G -----|-----------------------------------------|------------- raw | preallocated: disk capacity (getSize()) | disk capacity | thin (sparse): 1M | (there is no raw sparse on block domains) Verification should include a storage domain with and without enough space for all the vm (with disks) in the pool . In case of insufficient space a relevant CDA message should pop. --- Additional comment from Vered Volansky on 2014-09-29 10:33:19 IST --- Since this is thinly provisioned, only sparse-qcow is in use here (from above table). Note in this flow the template already exist, so no allocation checks for it, and the allocation checks taken from the table above should be applied to all VMs (empty volume space* numOfVms). ------------------------------------------------------------------------------- This bug is a RHEV tracker for the QE team to verify against RHEVM 3.5.0
For some reason, when creating a pool of VMs out of a template, the allocation check is being done according to the virtual size of the disk. For example, pool creation for 5 VMs out of a template, which its disk virtual size is 5G (actual 1G since it's sparse), on a domain that has 20G free space will be blocked on CDA of not enough free space on domain. I Conversed with Allon. We agreed that this is not the desired behaviour. Allon, Please advise how to proceed, thanks.
Also, the validation should consider also the value of FreeSpaceCriticalLowInGB, which is 5G by default (can be changed). In my setup, the value is the default (5G)
Vered is investigating, moving the needinfo to her.
(In reply to Elad from comment #1) > For some reason, when creating a pool of VMs out of a template, the > allocation check is being done according to the virtual size of the disk. > For example, pool creation for 5 VMs out of a template, which its disk > virtual size is 5G (actual 1G since it's sparse), on a domain that has 20G > free space will be blocked on CDA of not enough free space on domain. > > I Conversed with Allon. We agreed that this is not the desired behaviour. > > Allon, > Please advise how to proceed, thanks. Additional insight: the situation described in comment 1 is a faulty allocation check that takes into consideration the size of the template's disk, instead of just a thin QCOW layer on top of it per VM in the pool. The meaning of this is that if the template uses preallocated disks, you must have enough space for another preallocated disk per VM in the pool, effectively killing the notion of over-committing storage. Thus, marking as a REGRESSION.
Tested with 3.5 v3.18 Moving to verified
bugs were moved by ERRATA to RELEASE PENDING bug not closed probably due to errata error. closing as 3.5.0 is released.