1. Proposed title of this feature request Allow qcow files with backing file for templates disks based on other templates disks 3. What is the nature and description of the request? When templates are based on other templates, storage consumption is non-optimal (multiple copies) and template creation is slow, as all storage is copied to a new disk image. Additional performance benefits may exist, due to improved cache efficiencies. 4. Why does the customer need this? (List the business requirements here) This feature would reduce storage consumption, and potentially improve storage performance. 5. How would the customer like to achieve this? (List the functional requirements here) An additional option is needed for creating a template (GUI and API), to allow the disk(s) for the template to make use of the parent templates disk(s), as a backing file. 6. For each functional requirement listed, specify how Red Hat and the customer can test to confirm the requirement is successfully implemented. - Create VM A, with one or more disks - Make Template A, based on VM A - Create VM B, based on template A - Create Template B, based on VM B while specifying the new option, for example 'qcow with backing file' format. - The disk(s) for template B should be qcow format, with backing file the disk(s) of template A - Create VM C, based on template B - Create Template C, from VM C, while specifying 'qcow with backing file' format. - The disk(s) for template C should be qcow format, with backing file the disk of template B 7. Is there already an existing RFE upstream or in Red Hat Bugzilla? Not that I am aware of. 8. Does the customer have any specific timeline dependencies and which release would they like to target (i.e. RHEL5, RHEL6)? No, but this will increase the value of RHEV significantly due to reduced storage consumption. 9. Is the sales team involved in this request and do they have any additional input? No 10. List any affected packages or components. RHEV-M template creation dialogs and API, and vdsm 11. Would the customer be able to assist in testing this functionality if implemented? Yes
We are planning to move to Cinder and smart storage offloading. This will make all templates thin be definition.
We are past 4.5.0 feature freeze, please re-target.
The cost-effectiveness of this RFE is really low - adding dependency between templates doesn't exist, and using thin provisioning would not necessarily improve the performance