Create a new VM and base it on a template in two methods, thinly provisioned or cloned. 1. When thin provisioning is chosen, AddVmCommand is called, and a VM is added with empty disks, thinly provisioned from the template. Storage Allocation checks in this case should take into consideration that the new disks will always be SPARSE/COW, i.e., 1G on block domains, 1M on file domains, according to the tracker bug tables (bz960934). 2. When clone is chosen, AddVmFromTemplateCommand is called, and a VM is added with cloned disks, cloned from the template, where the regular validations for cloned disks should be made: | File Domain | Block Domain -----|-----------------------------------------|------------- qcow | preallocated : 1.1 * disk capacity |1.1 * min(used ,capacity) | sparse: 1.1 * min(used ,capacity) | -----|-----------------------------------------|------------- raw | preallocated: disk capacity |disk capacity | sparse: min(used,capacity) Verification should include a storage domain with and without enough space for the vm (with disks). Special care should be taken with the right verifications in these two specific flows. In case of insufficient space a relevant CDA message should pop.
Additional insight: In 3.5.0, before the patch referenced in the tracker, there was a faulty allocation check that took into consideration the size of the template's disk, instead of just a thin QCOW layer on top of it. The meaning of this is that if the template uses preallocated disks, you must have enough space for another preallocated disk when adding a VM based on it, effectively killing the notion of over-committing storage. Thus, marking as a REGRESSION.
Verified with v3.5 vt13.8
bugs were moved by ERRATA to RELEASE PENDING bug not closed probably due to errata error. closing as 3.5.0 is released.