Description of problem: Currently in RHEV-M we provide the ability to chose between two disk allocation policies: "Thin Provision" or "Preallocated". Scope of this RFE is to request the ability to choose between raw-sparse and qcow2 in case "Thin Provision" is selected, and to make the full stack aware of the choice made. Reason for this RFE is that creating a template from a vm using qcow2 disks or provisioning from existing templates takes a long time because of this "unawareness". Version-Release number of selected component (if applicable): 3.4 How reproducible: always Steps to Reproduce: 1. Add a virtual Disk 2. select application policy "thin provision" 3. Actual results: There is no control over which kind of thin provision disk is created. Expected results: Being able to decide between raw sparse and qcow2. Additional info:
Sounds like a nit, let's re-review after handling bug 1142762
According to ImagesHandler#checkImageConfiguration, we don't support the following configuration: storageDomain.getStorageType().isBlockDomain() && volumeType == VolumeType.Sparse && volumeFormat == VolumeFormat.RAW So should we drop this check or should we present the option of raw-sparse only for file-domains?
(In reply to Arik from comment #4) > According to ImagesHandler#checkImageConfiguration, we don't support the > following configuration: > storageDomain.getStorageType().isBlockDomain() && volumeType == > VolumeType.Sparse && volumeFormat == VolumeFormat.RAW > > So should we drop this check or should we present the option of raw-sparse > only for file-domains? Raw-sparse isn't support on block domain in the storage level - don't remove it :-) This RFE is about ADDING the ability to have the base volume cow-sparse when creating a template.
(In reply to Allon Mureinik from comment #5) If I understand the code correctly, we currently provide only two options: preallocated and thin provision. On file-based domains thin provisioning is mapped to sparse+raw and on block based storage it is mapped to sparse+cow. At the beginning I thought that we're asked to provide 3 options (for every storage type): 1. preallocated 2. thin provision (cow) 3. thin provision (raw) But since raw-sparse is not supported on block domain, we just need to provide the option for cow-spase for file-domain? Or my observation of the current state is wrong?
On file domains, raw+preallocated doesn't make any sense for a template (it's not as though it's going to grow), and moreover, any half decent file system will just ignore the preallocation request. I think we should remove the notion of having the user choose thin vs. preallocated, and just have them choose the format. QCow always implies SPRASE. RAW on file implies SPARSE, while RAW on block implies PREALLOCATED.
ovirt-3.6.0-3 release
From the description - "Scope of this RFE is to request the ability to choose between raw-sparse and qcow2 in case "Thin Provision" is selected, and to make the full stack aware of the choice made." From comment #5 - "This RFE is about ADDING the ability to have the base volume cow-sparse when creating a template." This comment is based on one simple use case that was givenas an example in the description. I think we should make the changes all over, this is the original request. Taking RFE and marking it as fixed while fixing only single use case is mistake. Yaniv, please advice here. in case we will go with current, we will mark it as verified and will open the same RFE for fixing all other place.
(In reply to Aharon Canan from comment #10) > This comment is based on one simple use case that was givenas an example in > the description. > I think we should make the changes all over, this is the original request. > Taking RFE and marking it as fixed while fixing only single use case is > mistake. No, that's called SCOPING. > in case we will go with current, we will mark it as verified and will open > the same RFE for fixing all other place. Please do.
I think different than you. Yaniv, as you are the PM and the one who represent the costumers needs, your call.
I have created a RFE for create VM from template and Tim created a separate RFe for his use case. Please verify the current RFE on creating a template.
Following comment #31 - scenario was tested and passed (comment #8) Verified.
Arik, can you please add some doctext to this RFE? Thanks!
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://rhn.redhat.com/errata/RHEA-2016-0376.html