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)?
-
I agree, got a similar dilemma now.
Required to grant permissions to single host (gpu computing) and ability to create\remove VMs.But it looks it no ACL for VM creation, it available only for global admin\pool admin accounts. So only way is setup standalone XO for each single host? This way i lose the pool storage and VM migration.
-
@Tristis-Oris said in Permissions Make No Sense:
I agree, got a similar dilemma now.
Required to grant permissions to single host (gpu computing) and ability to create\remove VMs.But it looks it no ACL for VM creation, it available only for global admin\pool admin accounts. So only way is setup standalone XO for each single host? This way i lose the pool storage and VM migration.
I'm glad someone else came across the same issue I was encountering (still don't have a solution) but maybe the vates team is working on it.
-
If you want to get more than permission on existing objects, you need to use the self service, it's made exactly for that.
-
@olivierlambert but, what is this?) i see nothing at docs.
ah. this self service, not a build-in acl group.That mean i need to create some VM templates and share them to user, but even devs don't know what they will need.
This more a bout resource limitation, which is not my task. Or i'm wrong? -
@Tristis-Oris you can read up on it here, https://xen-orchestra.com/docs/users.html#self-service-portal
While Self-Service might "scratch the itch" I've been able to talk my team off the edge and just let me manage the environment and grant them access to the VM's through other means.
-
@DustinB yeah i already remember about that button. Still not sure is it suitiable for me. Need to check it again.
-
yes, it almost what i need, really great. But you can't setup host affinity via self-service VM creation. Since i have different GPU on hosts, some persons required only 1 host from the whole pool.
self
basic admin
-
you can't configure vGPU limitation at self-service rule, but user can select vGPU at VM creation based on that rule. So it would be unlimited. But i can't really check it with my nvidia cards.
and what is
Share this VM?
