At work, one of our vSphere datacenters has a relatively static VM count maintained by a single group operating under the vCenter Administrator role. Recently, another group has joined this datacenter and will need to provision 60+ VMs, then hand over the VMs to us for ongoing maintenance and occasional provisioning of 1-2 VMs at a time. We do not want to make these users Administrators, nor do we want to provision 60+ VMs. To make this work, these new users need more rights than the VM Power User role during initial provisioning; some rights will be taken back when they move to maintenance mode. vCenter doesn’t provide any roles that match either need, so I had to create one that had all the correct permissions.

As the built-in roles do not provide the proper permissions, some trial and error was required to determine the correct combination of permissions for our situation. I do not expect that these permissions fit everyone’s needs. Please take the time to test and ensure whatever settings you do choose hit the right balance between your user’s needs and security considerations.

Side note: User rights in the vCenter Web Client appear to be checked upon logon by the client, but upon use by vCenter (and the C# client is dead, remember?). When adding rights, you will need to log out and back in to the Web Client for appropriate menu items to be enabled. When removing rights, the menu items are still enabled but fail upon attempting to use them. I would suggest always logging out and back into the Web Client after changing permissions of the logged in user. A strong dose of patience will help as well, the flash client can leak memory and really slow down, especially if you’ve got one browser running it for your admin user and another for your test user. At least one instance of IExplore.exe was killed in the process of making this blog post!

As in any good design, we need to lay out the requirements, the constraints, and the unspoken assumptions to ensure the final product makes everyone happy. Here is our situation:

• This new group has their own datastores that the Administrators created, but they have full control over the datastore contents. They can upload ISOs to their heart’s content, they can wipe out vmdk files, fill up the drive with 1’s, whatever they want, they’re in control.
• Our new group will be using the vCenter Web Client only.
• Administrators will provide a single base template of the correct OS with the minimum required CPU, RAM, and hard drive resources. A single NIC in the appropriate portgroup is attached.
• During provisioning, the new group will convert the templates to VMs, install the correct software, test, and mark the VMs as templates again.
• The Administrators will provide a small amount of assistance in cloning this single template to a large/medium/small configuration of compute and storage resources to prevent overprovisioning of VMs.
• During provisioning, the group will create their own folder heirarchy.
• During provisioning, the group will deploy 60+ VMs on their own, from templates only.
• During provisioning, the Administrators will provide oversight to ensure the process is working and assist in any issues.
• After provisioning, the group’s rights will be lowered and future provisioning will fall to the Administrators (the rate of new VMs is expected to be <5 per quarter).
• The new group is trusted by the Administrators unless oversight shows otherwise.

I emphasize the last assumption. The goal is to save time by allowing this other group to do work without requiring the Administrator’s constant involvement, after all. Without trust, the exercise is a waste of time and the Administrators might as well do everything themselves. With all that in mind, it’s time to start creating roles.

You can find the roles in the Web Client from the Home page. Click on Administration on the left hand side, then Roles. I started by cloning the provided Virtual Machine power user (sample) into a role called <Group> User, modifying it some, and then cloning that role to <Group> Provisioning and adding the final permissions. We yank two sets of permissions, then add a few more. Most are self explanatory, for the rest I’ve provided some detail on why I chose them so you can evaluate its usefulness in your setup.

<Group> User:

• Configuration / All – Uncheck everything. We’re forcing our new group to deploy templates, as you’ll see below, and not allowing changes to the VMs they provision. You can stick with the original settings if your users are allowed to configure their VMs resources.
• Configuration / Configure floppy media – Disable – We’re not using floppies, so this is just consistent with removing the floppy and disabling it in the BIOS of our VMs.
• Datastore / Allocate Space
• Datastore / Low level file operations – This allows a user to add and remove files to their datastore. There are no more granular access controls, you cannot allow someone to upload files but not modify or delete files.
• Folder / All – In our situation, I want our users to be able to create their own heirarchy. I am able to limit this ability further, below.

<Group>Provisioning:

• Everything that User has, plus…
• Resource / Assign virtual machine to resource pool – Without this permission, you cannot assign a new VM to a DRS cluster. We don’t have any standalone hosts, I was unable to test if this is required for non-DRS hosts.
• Inventory / Create from existing – You’ll need this to deploy from templates, which our users do.
• Inventory / Register – This is required to add a virtual machine to the inventory. Why this is a separate permission and not associated with the permission above (or other permissions) to restrict this feature to VM creation, I am unsure, but if you forget this you won’t notice until you get to the end of a VM creation or template deployment wizard.
• Provisioning / Customize – This allows customizing the guest OS only, nothing else about the VM
• Provisioning / Deploy template
• Provisioning / Mark as template
• Provisioning / Mark as virtual machine – This and the prior permission allow our Provisioning users to create and update their own templates during this bulk provisioning process
• Provisioning / Read customization specifications – You’ll have to create the customization specs for the Provisioning team, this only lets them use the specs.

To make this work, there were a few more things to I had to do. I created a VMs and Templates Folder called <Group> and two folders underneath it, <Group> VMs and <Group> Templates. I also created two datastores, <Group> ISOs and <Group> VMs and put those in a Datastore Folder called <Group> Datastores. Assign your two roles to <Group> VMs, <Group> Templates, and <Group> Datastores. Do not assign the role to <Group>. Last, assign the <Group> Provisioning role to any DRS clusters that VMs are allowed to be created on.

When you assign the roles, I suggest using a different SSO group for each role. We use Active Directory with our SSO, like many, so I created groups vCenter <Group> Provisioning and vCenter <Group> Users. By doing this, you allow the users in this group the ability to provision everything they need, then by emptying the membership of the provisioning group, you restrict the users to the User role.

One other thing. Along the way, I found one issue that had me scratching my head for a bit. I changed the name of my AD group and my test user suddenly had no rights. This happens through a somewhat surprising, yet intuitive, issue with SSO/AD integration – when you assign the SSO role, it maps to the group name as provided at the time of role assignment. It appears the string (CN or qualified) is saved, not the user/group ID. Once you change the user or group name in AD, the user or group loses that role on next logon. I did not try restoring the group name to see if permissions were restored afterward. I would highly recommend that you ensure your AD group names comply with any naming convention you use before you assign roles and then never change them afterward. This is especially important with your Administrator group(s); make sure you keep your SSO administrator@vsphere.local password somewhere safe!