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?
5 Answers
Some MSPs will resist shared administrative access because their contract makes them accountable for the entire platform. Before changing permissions, update the contract or responsibility matrix so it explicitly says what happens when an internal change causes an outage, consumes capacity, breaks backup coverage, or violates security policy. Include audit logging, approval requirements, rollback expectations, and a rule that the MSP will not silently undo internal changes.
If the MSP will not support co-management, the practical alternatives are a better SLA and self-service workflow, or moving to a provider whose service model supports direct vCenter and API access. A shared environment without explicit accountability is usually worse than either a cleanly managed service or a cleanly self-managed platform.
The technical split is possible, but the operating agreement matters more than the permissions. Define exactly who owns VM provisioning, guest OS support, backups, restores, snapshots, networking, security controls, monitoring, capacity approvals, and incident response. Every change should still go through your change-management process and be logged, regardless of whether your team or the MSP performs it.
Also agree on guardrails: quotas, approved templates, snapshot age limits, naming standards, backup requirements, maintenance windows, escalation paths, and who can change DRS or resource-pool settings. Without those boundaries, shared administration becomes a blame-sharing exercise when something breaks.
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.
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.
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.
The current workflow sounds unnecessarily repetitive: creating an internal ticket, emailing the MSP, waiting for another ticket number, and copying the result back. Improving that process or integrating the ticketing systems may solve part of the problem even before permissions are changed.