Description of problem: Storage space allocation (or verification) of new disks should be done as follows: For new empty disks: | File Domain | Block Domain -----|-----------------------------------------|------------- qcow | 1M (header size) | 1G -----|-----------------------------------------|------------- raw | preallocated: disk capacity (getSize()) |disk capacity | thin (sparse): 1M (as qcow) | For cloned disks: raw: min(used, capacity). qcow: 1.1*raw Actual results: Incorrect memory allocation (not compliant with the above) in all disks allocations throughout the system. Expected results: Correct memory allocation. Additional info:
(In reply to comment #0) Refining with Allon the requirements... For new empty disks (unchanged from the original) | 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) For cloned disks: | 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)
*** Bug 1024269 has been marked as a duplicate of this bug. ***
Sean, Ayal, I'd like your input as to how to treat this bug. The two patches in the external tracker introduced all the infrastrcuture required to implement the solution for this bug: 1. http://gerrit.ovirt.org/#/c/15377/ Added the ability to CORRECTLY validate the storage requirements for a newly created volume, and applied it to the Add Disk flow. 2. http://gerrit.ovirt.org/#/c/22447/ Added the ability to CORRECTLY validate the storage requirements for a new volume that should contain data, and applied to the Move Disk (both cold and live) flows. There are, of course, several other flows that are still lacking - create VM, create template, create snapshot, etc... Should each have a separate bug? Should we have a single bug and close it only when we're finished with all of them?
(In reply to Allon Mureinik from comment #18) > Sean, Ayal, I'd like your input as to how to treat this bug. > > The two patches in the external tracker introduced all the infrastrcuture > required to implement the solution for this bug: > > 1. http://gerrit.ovirt.org/#/c/15377/ > Added the ability to CORRECTLY validate the storage requirements for a newly > created volume, and applied it to the Add Disk flow. > > 2. http://gerrit.ovirt.org/#/c/22447/ > Added the ability to CORRECTLY validate the storage requirements for a new > volume that should contain data, and applied to the Move Disk (both cold and > live) flows. > > There are, of course, several other flows that are still lacking - create > VM, create template, create snapshot, etc... > Should each have a separate bug? > Should we have a single bug and close it only when we're finished with all > of them? depends on when you want it checked. in general I'd go for a single bug and specify all the scenarios that need to be covered and how to test them. But this is only assuming that all the patches get in in a short time frame.
(In reply to Ayal Baron from comment #19) > (In reply to Allon Mureinik from comment #18) > > Sean, Ayal, I'd like your input as to how to treat this bug. > > > > The two patches in the external tracker introduced all the infrastrcuture > > required to implement the solution for this bug: > > > > 1. http://gerrit.ovirt.org/#/c/15377/ > > Added the ability to CORRECTLY validate the storage requirements for a newly > > created volume, and applied it to the Add Disk flow. > > > > 2. http://gerrit.ovirt.org/#/c/22447/ > > Added the ability to CORRECTLY validate the storage requirements for a new > > volume that should contain data, and applied to the Move Disk (both cold and > > live) flows. > > > > There are, of course, several other flows that are still lacking - create > > VM, create template, create snapshot, etc... > > Should each have a separate bug? > > Should we have a single bug and close it only when we're finished with all > > of them? > > depends on when you want it checked. > in general I'd go for a single bug and specify all the scenarios that need > to be covered and how to test them. > But this is only assuming that all the patches get in in a short time frame. Due to priority considerations, we cannot guarantee that. I'll leave this BZ as a tracker, and open a new BZ for each usecase, so we can tackle (and test!) them as they come.
Some notes regarding verification of the dependent bugs: First, we have two use cases for volume creation: 1. Empty Volumes - Create a new disk, create snapshot (a new, empty volume is created in this case). 2. Cloned volumes - An empty volume is created, immediately followed by filling in with the data (When moving a disk, cloning, exporting, creating from a template/snapshot etc.) All the allocation-related scenarios in the system can be taken apart to consist one or both of these cases. When verifying, both positive and negative test cases should be verified: Verify against a storage domain with and without enough space - just about the needed/excess space for the disks. Verify it succeeds when there's enough space and fails on CDA when it doesn't. Usually threshold should also be verified for a complete verification (again, positive and negative). If we're dealing with a VM with memory volumes, their space should also be taken into consideration (in some cases for every snapshot, depending on the use case). The metadata volume's is always of size 10KB, Cow, Sparse. In file domains this size is negligible, but bare in mind that block domains have a minimum block size of 1G. The memory volume's size varies, is always RAW, and is Sparse for file domains and Preallocated for block domains. New volumes are always RAW, except thinly provisioned on block domains. Snapshots are always qcow and consist of only a header. The domain's type (file/block) determines the minimum size for this header: 1M for File and 1G for Block.
This is a tracker bug. Since all the dependent bugs are MODIFIED (or better), moving this one to MODIFIED too.
This bug depends on several RHEV bugs which are all ON_QA and several oVirt bugs in MODIFIED. The oVirt bugs will be moved to ON_QA when oVirt 3.5.1 is built. However, this code is included in RHEV 3.5.0's recent builds, so the RHEV tracker can be moved to ON_QA too.
More details as to how to verify were added in comment #21. Note that the storage allocations implementation ALWAYS took into consideration the threshold limitations. Storage devel advised how this should be verified, since it seemed to be unclear. No advice was entered on thresholds since this is clear. Just so there are no misunderstandings - thresholds are being validated in the code throughout all these bugs.
Clearly there are some items here that failed qa and require fixing, but we won't delay 3.5.0 for this. Pushing out to 3.5.1 to handle properly.
Moving to 3.6.0 since this will not converge to 3.5.z.
moving old bug fixed before ovirt alpha release as fixed in current beta2, 3.6.0-9.
Moving tracker to verified as all "depends on" bugs on verified/closed