Permissions Make No Sense
-
So I have a need to allow a subset of users within my org to access XO to be able to create VMs.
Ideally I want to limit them in the below ways:
- Restricted to a singular host of the pool
- Restricted to a singular SR of the pool
- Unable to affect other workloads
- They must be able to create/destroy VM's on this singular host
I built an ACL that grants them admin access to the Host, the SR and operator for basically everything else.
Oddly, even with Admin access to the host, they couldn't create VMs, I had to grant the ACL admin access to the Pool - this really sucks - to be able to allow them to create VMs.
Is there a better way that permissions should be setup that I'm missing? If you have access to view the pool, I would think that delegated administrative access to a singular host, would allow one to create VMs on that host.
Separately, when the user was able to create a VM, they were unable to set Host Affinity at the time of creation, but could do so after the VM was created (and starting).
-
I think that Granular Delegated Admin Permissions should be applicable to an environment.
Starting with the least permissive, being no permission at all
Then View Only at the pool level
Then Operator at the pool or host level
Then Administrator access at the pool or Host levelThe way permissions appear to work today, are the inverse, with requiring administrative permissions on the Pool, even if you only actually have access to a singular host in the pool.
-
I think the problem is that as soon as a host is a member of the pool everything created "belongs" to the pool and not the host.
You'd have to setup a standalone host to be able to achieve what you want since that "single" host would create its own "pool" where itself is the only member. -
@nikade said in Permissions Make No Sense:
I think the problem is that as soon as a host is a member of the pool everything created "belongs" to the pool and not the host.
You'd have to setup a standalone host to be able to achieve what you want since that "single" host would create its own "pool" where itself is the only member.No company of any scale is going to have a standalone host for this though. It arguably only makes sense to get GDAP style permissions created, where you have the ability to limit what can happen within the entire pool, this way you don't have separate sets of permissions on differing workloads.
-
@DustinB said in Permissions Make No Sense:
@nikade said in Permissions Make No Sense:
I think the problem is that as soon as a host is a member of the pool everything created "belongs" to the pool and not the host.
You'd have to setup a standalone host to be able to achieve what you want since that "single" host would create its own "pool" where itself is the only member.No company of any scale is going to have a standalone host for this though. It arguably only makes sense to get GDAP style permissions created, where you have the ability to limit what can happen within the entire pool, this way you don't have separate sets of permissions on differing workloads.
Yeah thats correct, you wont be able to pin permissions to a specific host.
So far we havent had the need to do so, we just delegate X cores, Y Gb RAM, Z Gb disk and thats about it. For us it doesnt matter what hosts in the pool that our dev's runs their VM's. -
@DustinB
Does the Self Service resource sets not cover your needs? I understand wanting to limit resources so they don't impact others, but pinning down to a specific host that may be a part of a larger pool can make ACLs ugly. Especially when you enable HA or Plans/DRS. If you aren't planning to enable those features, why not leave the host as an independent pool and give them access that way? -
@jimmymiller said in Permissions Make No Sense:
@DustinB
Does the Self Service resource sets not cover your needs? I understand wanting to limit resources so they don't impact others, but pinning down to a specific host that may be a part of a larger pool can make ACLs ugly. Especially when you enable HA or Plans/DRS. If you aren't planning to enable those features, why not leave the host as an independent pool and give them access that way?No, SS doesn't address the ask.
-
@DustinB So what features about the pool are you wanting to use that you can't just give them access to the individual host (i.e. as a single host pool)?