1. Proposed title of this feature request - Allow multiple quotas to one template other then Blank 3. What is the nature and description of the request? - Currently there is not a way to have different groups that have quota assigned to them to share a template other then Blank. 4. Why does the customer need this? (List the business requirements here) - This requires additional maintenance on replicated templates. Meaning that instead of 5 templates to manager, the admin now may need to maintain 20 templates. 5. How would the customer like to achieve this? (List the functional requirements here) - Create a template for anyone to use. Create a group of users and assign the users a quota, the user can log into the VM portal and create the VM based on any template they have permissions to use. 6. For each functional requirement listed, specify how Red Hat and the customer can test to confirm the requirement is successfully implemented. - Create a template for anyone to use. Create a group of users and assign the users a quota, the user can log into the VM portal and create the VM based on any template they have permissions to use. This is not to far off of what is the current status, however if the template has no quota assigned to it, it should fall back to the user/group quota 7. Is there already an existing RFE upstream or in Red Hat Bugzilla? - Not that I have seen. 8. Does the customer have any specific timeline dependencies and which release would they like to target (i.e. RHEL5, RHEL6)? - No, they are going live with their RHV deployment soon. They now understand that they have to create additional templates. 9. Is the sales team involved in this request and do they have any additional input? No 10. List any affected packages or components. Not sure 11. Would the customer be able to assist in testing this functionality if implemented? Yes
After working with the customer, I can see how this would be vary helpful. What we continued to run into, is that when a Template is created there is always a quota assigned to that template. We are looking more for the option like template 'Blank' where there is not a choice or not required to assign a quota to that. This should be left to other permissions Sam
Hi Sam, I'm trying to understand what is the request. As you wrote, `Blank` can't be assigned with quota. Other templates can be assigned with a quota, to be their default. In webadmin, you can select/change the quota of the new created VM. For `Blank` it should be the `Default` quota even when the template itself doesn't assign with it. In VM portal, which mostly for users - not admins - you can't select this quota on creation. The meaning is created a VM with the assigned quota of the template. It makes sense as the admin set rules for an entity and user shouldn't change it. Are you requesting this option to appear on VM portal as webadmin? What do you mean by multiple quotas? A template/VM can have one which has CPU/Memory/Storage limitations. What do you mean by: "This should be left to other permissions"? Generally speaking if you set `Default` quota, in my opinion it should act as `Blank` in terms of quota.
Hi Liran, I am the customer who requested this (Case 02933112) - the issue we are running into is we have multiple quotas for multiple teams. When you create any VM template it has to be assigned a single quota. This causes issues because now I have to create another identical template for my other quotas and teams. Example: Quotas: Quota 1 Quota 2 Quota 3 Templates: Template 1 (Red Hat 8) Assigned to quota 1 Template 2 (Red Hat 7) Assigned to quota 1 Template 3 (Ubuntu 20.04) Assigned to quota 1 With the above example, If I want my quota 2 and quota 3 groups to have access to templates I have to replicate all the templates for these groups giving me multiple and identical "Red Hat 8", "Red Hat 7" and "Ubuntu 20.04" templates. In our case we have 6 groups and 6 quotas, I have 6 Red Hat 8 templates, 6 Red Hat 7 templates, 6 Ubuntu 18 templates, 6 Ubuntu 20 templates, 6 Windows 10 desktop templates, 6 Windows server 2016 templates, 6 Windows server 2019 templates. The request is instead of assigning a template to a quota, have the template not assigned to anything and it automatically accounts for resources based on groups. Hope this explains it. I will be more than happy to jump on a call or do screenshare if you need more info.
Some off-line discussion: >> In the webadmin, we allow the user to create a VM from a template and assign it with quota. >> In the VM portal, we can't. Not only that, the users don't have access at all to those templates. >> Currently, the customer needs to make replicates of the same template with different quotas per each group. > > > The user has access to templates based on user permissions but here the issue is not related to granted permissions per user/group (since the user can see those templates and select them via VM portal upon VM creation) but it's related to quota assignment since a user should be a consumer of a quota that is assigned to the resource/template. > > By design the current behaviour for non admin users is that if such a user/user-group is a consumer of for example quotaA, it can create a VM based on template assigned with quotaA only. > Even if we would like to let the user select the quotas from a list on the VM portal (which we aren't since users shouldn't deal with quotas) then the only option that the user will anyway be able to choose from in our example is his consumed quotas which is quotaA. > If there is a template assigned with quotaB, then it won't work. > > The 'Blank' template is a special case since no quota is assigned to it and we do want to always let users create VMs based on 'Blank' template, so we decided that the one of the user's consumed quotas will be selected as the created VM's quota (default or the first one in the list). > > >> >> The only 'working' template is Blank, in it is a special case. As far I can see it, we need to: >> 1. Give access to users on other templates (is it a bug for itself? as long as the user has a role to create a VM from template? if not, will it cause a security issue seeing those?). > > > As detailed above, it's not a matter of giving permission access so it's not a security issue. It's more an issue of how we make sure that the quota assignment limitations work as expected. > >> >> 2. Upon creation, let the user select the quota he wishes from his quota group. > > As detailed above, this won't work as well since the user can choose only the quotas assigned to him (or to the groups he belongs to). > >> >> 3. If nothing is given it should auto-set by default, if it had a quota that the current user wasn't part of, it will need "a switch" to one of those he does. > > > I think that there are 2 use cases here: > 1. How it works today: > - The admin assigns a user/user-group with a specific quota since he wants to set a specific resource limitation for that non admin user. > - He also assigns a template with a specific quota since he wants the resources consumption to be limited for that template usage. > - If the user wants to create a VM based on that template, he needs to have permissions to that template (security reasons) and also to share the same quota as set for that template (resources consumption reasons). > - If the admin doesn't want to set any resource limitation for a user and a template then he can assign both with the default quota and it should work today as well. - > So I don't think that we always want to avoid that use case and cancel this implementation > > 2. templates without assigned quota (same as for Blank template): > - The admin assigns a user/user-group with a specific quota since he wants to set a specific resource limitation for that non admin user. > - He set a specific template without any quota (no specific resources consumption limitation for that template). This should be set by a template property or by leaving the quota field empty for the template). The same as for 'Blank'. It shouldn't be set on the VM portal since it's not a user decision to make. > - If the user wants to create a VM based on that template, he needs to have only permissions to that template (security reasons) but he doesn't need to share the same quota. Once the VM is created, the same logic as for 'Blank' is used, i.e. the first quota consumed by the user will be set to that VM. > > With #2 the customer will be able to set his template without any assigned quota (no resource limitations) and then all users will be able to create VMs based on that template by granting the user's/group's quotas only. > > WDYT? Thanks for the detailed answer. To be honest, I agree quotas should be for admin and not visible to the users(like you mentioned in use case 1). But we do need to think about how to save duplicating templates for that matter. Use case 2 seems valid to do so, as the customer wishes to have the "Blank" template behavior on others. Do we currently support it(vm portal? as i thought it's possible only with the blank template)? Sam, does it sound reasonable? It doesn't seem right to allow users selecting a quota.
Hi Liran, Option 2 is what the customer is looking for. To create a template without assigning a quota (no resource limitations), then all users with the correct permissions to that template can create a VM and it will go against the group/user quota only.
(In reply to schandle from comment #8) > Hi Liran, > > Option 2 is what the customer is looking for. To create a template without > assigning a quota (no resource limitations), then all users with the correct > permissions to that template can create a VM and it will go against the > group/user quota only. Does it work if you clear the quota for that template in the database?
Meaning: update vm_static set quota_id=NULL where vm_name='<the name of your template>';
I'm changing the title of this bug because an entity should not be correlated with more than one quota by design. The request here is different and that is to enable users that are not assigned with the quota that a template is assigned with to provision VMs from that template. The way it was achieved in the past is by letting users to choose the quota they'd like to set for the create VM (that was possible also from the user portal). Since there is no way to do it from the VM portal (web-ui) as it doesn't have quota support (again, by design), there needs to be a workaround like the one introduced for the blank template. Clearing the quota of the template in the database (note that in addition to what's written in comment 12, one would also need to clear the quota on the template disk(s)) can be such a possible workaround.
web-ui patch fix https://github.com/oVirt/ovirt-web-ui/pull/1495 was merged.
(In reply to Sharon Gratch from comment #15) > web-ui patch fix https://github.com/oVirt/ovirt-web-ui/pull/1495 was merged. Thanks, you can close bz 1991240 then :)
Verified on RHV 4.5.0-4. Env: - Engine instance with RHV 4.5.0-4 (ovirt-engine-4.5.0-0.237.el8ev) and RHEL 8.6 installed. - 3 hosts with RHV 4.5.0-4 and RHEL 8.6 and with vdsm-4.50.0.10-1.el8ev. Steps: In Admin Portal: 1. Log in as an admin user. 2. Create a 4.7 data center with a quota set to Enforced and a 4.7 cluster. 3. Create 2 non-admin users in the env, we will refer to those as user1 and user2 with the VMCreator role set in the cluster. 4. Install the hosts and create a new NFS storage domain. 5. Create an RHEL 8.6 VM. 6. Create 3 quotas with the names: TemplateQuota, UserOneQuota, UserTwoQuota 7. Create a template from the RHEL 8.6 VM with its quota set to TemplateQuota. 8. Add user1 as TemplateQuota quota's consumer. 9. Add user1 as UserOneQuota quota's consumer. 10. Add user2 as UserTwoQuota quota's consumer. In VM portal: 11. Log in as user1. 12. As User1, create a VM in the VM portal from the template, and it will succeed. 13. Log out. 14. Log in as user2. 15. As User2, create a VM in the VM portal from the template, and it will succeed. Results (As Expected): 1. Logged in as an admin user. 2. The 4.7 data center and the 4.7 cluster were created. 3. The users were created and set with the VMCreator role. 4. The host was installed and the NFS storage domain was created. 5. The VM was created. 6. The quotas were created. 7. The template was created. 8. Added user1 as TemplateQuota quota's consumer. 9. Added user1 as UserOneQuota quota's consumer. 10. Added user2 as UserTwoQuota quota's consumer. 11. Logged in as user1. 12. The VM was created successfully. 13. Logged out. 14. Logged in as user2. 15. The VM was created successfully.
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 (Moderate: RHV Manager (ovirt-engine) [ovirt-4.5.0] security update), 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://access.redhat.com/errata/RHSA-2022:4711
Due to QE capacity, we are not going to cover this issue in our automation