I received a question recently on another UNMAP post what are the minimum permissions required to run UNMAP with PowerCLI and finally got around to looking into it. Turns out it is very straight forward. If you run it with a read-only account–it will fail. Since it is creating a file and making changes some configuration authority is required. Running as read only will look like this:
So as it says, you need a Host.Config.Storage permission to run this. There are a variety of roles that provide for this that are built in to vCenter (administrator for instance), but if you want to get granular you can create your own user role to do just this.
The permission that is required as seen in the vSphere Web Client is Host -> Configuration -> Storage partition configuration.
Assign this permission and only this permission to a new custom role for the bare minimum.
Now you have to assign this to an object and there are a few ways to handle this. Unlike some other PowerCLI commands that are run against the vCenter, UNMAP is run directly to a host (after a vCenter connection) because it is a esxcli command, which requires a host object from get-vmhost. Therefore, the user needs a role with the Host.Config.Storage permission assigned to whichever host you will be running UNMAP from. So, the options are:
- Pick the host you want to run UNMAP for and assign the user this role (for the greatest security granularity) or…
- Choose a cluster object or vCenter object (or any higher-level object in the inventory in which the desired host(s) are subservient to) and assign it to that object and let the children inherit the permission. This option will grant UNMAP access to your user for all of the hosts below that object in your vCenter inventory.
Below I am assigning the user with my custom role to the vCenter object and propagating it down.
One thing to note is that you do not need any actual permissions on the datastore, or really any child-object of the ESXi host. UNMAP will work with simply a Host.Config.Storage permission on the top level of the ESXi host with zero propagation. So basically it looks like if a user has this permission on a host, it can UNMAP any volume (that is of course actually presented to that host) even if they explicitly are given the “no access” permission on the datastore.