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