VC Permissions to Deploy Templates
VirtualCenter has all sorts of permission options. It is nice and flexible, but can take some guess and check work. Maybe this doc will save you some time. It was written with VC 2.5 in mind.
A common scenario is to delegate the creation of new virtual machines to others. This often times means deploying an existing template and customizing using an existing spec. This means giving up some permissions on four different objects.
- Template to deploy.
- Customization specs
- Resource pool (or cluster) where the new VM will live
- Folder in the DC where the new VM will live.
So you may not want to cover all of this with one role. It depends on how complicated your VirtualCenter layout is. For an example, I will setup permissions for a test user using the following VC layout.
- The template will be hosted in the LAB1 datacenter, in a folder named Templates.
- The template will be deployed to the Test2 cluster in the LAB2 datacenter.
- The destination VM will be placed in the MyFolder folder in the LAB2 datacenter.
For this scenario, I will use 4 different roles. I am trying to make it as complicated as possible to show the different areas that need permission modifications. As a disclaimer, there are probably some other ways to get this done.
ReadCustomizationSpecs Role
The first role gives the user/group access to read the existing customization specifications. This role should be applied at the top of the VC tree.
DeployFromTemplate Role
This role will give the user access to read the template. This one will be assigned to the folder named Templates inside the LAB1 datacenter.
AddToResourcePool Role
This role will give the user access to add the virtual machine to the cluster/resource pool. It will be applied to the Test2 cluster in LAB2 datacenter.
VirtualMachineDeployment Role
This last role is the general purpose role to allow the user to stick the VM in a folder and do things like power it on. This one would be right in between the “Virtual Machine User” and “Virtual Machine Power User” default roles.
Just a couple other bullet point notes.
- When testing permission changes, I recommend logging off the VIC and back on to make sure it takes effect.
- When you apply permission for a user/group that propagates, then apply another permission lower in the tree; you will not know the first one is there by looking at the lower object. VC will only show you this if you look higher in the tree. So by looking at an object, you cannot say definitively what the permissions are on it. VMware should get on fixing this one. chop chop.
And finally, the doc on VC permissions is located here. http://www.vmware.com/pdf/vi3_vc_roles.pdf
Hi Jeremy,
nice write-up! I discovered some “interesting” issues one would not expect when working with permissions in VC.
If you work with folders in “Hosts & Clusters” and “VMs and Templates” you have to be very careful:
Permissions are always treated differently between these two views, which is OK. Folders created above Datacenters will always share the same permissions. Folders created below Datacenters, even with the same name, will not automatically share the same permissions.
Also people might want to combine roles on one object, e.g. some users are in _create_hosts on Object1 (propagate=yes) but should also be given the right to create VMs on objects somewhere deeper in the hierarchie. Since you can only have on role associated to an object at one time you have to should groups and not single users . VC will then combine all roles/ permissions on that specific object, e.g. create hosts in folder1 and subfolders create VMs in
subfolder xyz…
Hope this helps or someone can comment.
Best,
Michael