I joined a small IT team a few months ago, and our MSP currently manages nearly the entire VMware environment. We have eight ESXi hosts in a cluster plus Azure, but even routine tasks such as resizing a disk, creating a VM, or changing a configuration require a request by email. Our goal is to improve flexibility and response times without taking responsibility for platform maintenance away from the MSP.
We would prefer the MSP to retain responsibility for hardware and firmware, ESXi and vCenter patching, storage-array administration, adding or removing hosts, physical and virtual networking changes, and cluster-level capacity planning.
Our internal team would like to manage normal VM operations, including creating, modifying, deleting, cloning, and snapshotting VMs; resource pools; vMotion and DRS settings; affinity and anti-affinity rules; templates; and access to host, cluster, and VM performance data, tasks, and events. We would also like to use RVTools and eventually automate VM provisioning with Terraform or Ansible.
Does this division of responsibility seem practical? Are there important responsibilities or controls we have overlooked, such as change management, backup and restore, snapshots, networking, security, monitoring, or capacity limits? Can vCenter RBAC provide enough separation for this arrangement, or would granting the internal team these permissions effectively require full administrator access? What agreements and safeguards should be in place so both the MSP and internal team have clear accountability when changes cause problems?
3 Answers
Keeping ESXi, vCenter, firmware, storage arrays, and physical networking with the MSP is a reasonable choice for a two- or three-person infrastructure team. Your team can still own the VM layer, but VM administration is not risk-free: templates, guest customization, virtual switches and port groups, snapshots, backup policies, and resource settings can all affect production.
I would separate routine VM operations from platform-level changes and start with a limited pilot. Give your team access to a designated VM folder, approved datastores and networks, and a small set of tested templates. Expand the scope only after you have demonstrated that provisioning, rollback, backup, documentation, and auditing work reliably.
vCenter permissions can usually support delegated VM administration without giving someone full vCenter administrator rights. The exact options depend on your vSphere version and architecture, but roles can be assigned at different inventory levels and propagated to folders, clusters, resource pools, or individual VMs. You can create a role that permits VM creation and lifecycle operations while excluding host configuration, storage administration, networking, and patching.
Test the role in a nonproduction folder first. Be especially careful with permissions involving resource pools, networks, datastores, templates, snapshots, and relocation, because some operations require privileges across multiple inventory objects. Use separate named accounts, least privilege, MFA where available, and an emergency administrative account controlled jointly under an agreed procedure.
The strongest argument for access is not simply wanting to view performance tabs; it is reducing a documented operational bottleneck. If VM deployment currently takes days because the MSP has to perform manual steps, propose a measurable service target or an automated workflow. Terraform or Ansible can be useful, but automation should be built around approved templates, quotas, tagging, IP and DNS integration, backup enrollment, and ticket or change-record creation.
You can also ask the MSP to provide read-only monitoring and event access immediately, then negotiate write access for a narrow set of VM tasks. That gives you faster troubleshooting without blurring ownership of hosts and the cluster.
Do not assume that a role which works in the web client will automatically provide everything needed by PowerCLI, Terraform, Ansible, or RVTools. Validate the actual API operations and make sure the automation account has only the permissions required for its scope.