One of the best ways I was able to evangelize virtualization to my early adopters was to leverage the robust role and permission model of vCenter Server. “Way back” in the VI3 days, the permissions and roles that were available with the vCenter Server made it very easy to deploy access and features. Application administrators could get console access; network and storage administrators could inspect configuration; and security or audit teams could check inspection requirements. Now with vSphere 5, a number of the new features have shown up in the privileges model and can be added to existing roles or used in new role creation.

Some of the new privilege elements include the ability to configure a datastore cluster. This is important, as the datastore cluster is one of the most critical vSphere 5 features, and the ability to configure the datastore cluster can be given to a user or group without wholesale administrative access. This privilege area is shown below in Figure A:

Figure A

Datastore clusters in Privileges

Other new features, such as the ability to view or update the new Profile-Driven Storage feature can be assigned as well, which are shown in Figure B:
Figure B

Profile-Driven Storage and other features

On many occasions in the past, I’ve taken the time to set up custom roles for stakeholders in the virtual environment. I want them to be able to get the information they need. I feel virtualization should not hide anything, and I’ve always been really impressed with the vSphere roles and privilege configuration. This allows people to log in with their Windows username and get whatever information they need. Honestly, most of the time I deploy read-only privileges, but sometimes to certain VMs or folders of VMs, I’ve allowed higher-permission features like virtual power button. Sometimes, I delegate full control, including to delete the VM to development areas for application development resources.

The takeaway is that you have options with the vSphere role and privilege model that can address almost any requirement. But above all, don’t over-permission access levels simply “because it always works” nor should we shun access because we can’t quite find the roles for it.

How have you leveraged the vSphere privilege and role environment as well as any new features with vSphere 5? Share your comments below.