I recently got a question from our field inquiring about the minimum vSphere privileges that would be required to either install or remove a patch (VIB/Component) from an ESXi host. The customer was interested in using PowerCLI and specifically the ESXLI interface to automate the installation and removal of a VIB and wanted to create a custom vSphere Role with the minimum privileges, which can be done with vCenter Server or even a standalone ESXi host (properly licensed).
Since I was familiar with the underlying ESXi patch API that is used for these operations, a nice benefit of the vSphere API Reference is that it also lists the specific vSphere Privileges that is required for a given operation and in this case, it is just Host.Config.Patch privilege.
However, when the customer attempted to create a custom vSphere Role with just this privilege and perform the installation operation, they still received an error as shown in the screenshot below, which was a bit cryptic but they had assumed it was still permissions related as full administrative account had worked:
OperationStopped: Response status code does not indicate success: 500 (Internal Server Error)
I had suspected an additional privilege might be needed and I was reminded of this 2013 blog post on the minimum vSphere privilege to query all install VIB/Components on an ESXi host and figured I give that a shot and sure enough, that was he additional vSphere Privilege that was required.
In summary, the following two vSphere Privileges are required if you wish to create a custom vSphere Role:
- Host.Config.Patch
- Global.Settings
I was able to manually confirm this by creating a custom vSphere Role on a standalone ESXi host (non-vCenter managed) called "Patching" that contained the privileges listed above. I then used PowerCLI (New-VIPermission) to assign the new vSphere Role to a custom user that I had already created on my ESXi host called "lamw". In the example below, I am installing and removing the USB Native Network Driver for ESXi component.
I now can use PowerCLI to login with this new user and when I perform a patch installation using the example snippet below, I no longer ran into the error as you can see from the screenshot below:
$esxcli = Get-ESXCLI -v2
$depot = "/vmfs/volumes/localhost-esx-install-datastore/ESXi703-VMKUSB-NIC-FLING-55634242-component-19849370.zip"
$dryrun = $true
$esxcli.software.component.apply.Invoke(@{depot=$depot;dryrun=$dryrun})
Lastly, we can also verify that uninstalling the patch with the same user also does not run into any issues as demonstrated with this example below:
$esxcli = Get-ESXCLI -v2
$component = "VMware-vmkusb-nic-fling"
$dryrun = $false
$esxcli.software.component.remove.Invoke(@{component=$component;dryrun=$dryrun})
Thanks for the comment!