A couple of weeks ago I had noticed a few internal folks were asking about missing Profile-driven storage privileges in vSphere 8.x when referring to 2nd party VMware documentation asking for two privileges called "Profile-driven storage update" and "Profile-driven storage view" which no longer exists in vSphere 8.x when compared to the vSphere 7.x documentation.
At first, I thought this was purely a rename issue as the underlying feature of these privileges has always been known as VM Storage Policies, which is even used in the vSphere 7.x UI and has been around for quite some time. It looks like in earlier releases, the vSphere UI label for the privilege was still using the older name.
Here is a a screenshot of a vSphere 7.x environment where you can see the original two privilege names:
Furthermore, it looks like these additional VM Storage Policy privileges have also not been updated in the vSphere 8.x documentation, which is currently a known issue and only references the renamed privileges.
Taking a closer look, I found that both the original two privileges and the renamed privileges in vSphere 8.x was purely a label rename, the underlying vSphere API privilege name for these two have NOT changed, meaning if you had built any automation using the privilege IDs, they would continue to work between vSphere 7.x and 8.x with the same behaviors.
Here is a table that outlines the changes between 7.x and 8.x:
|vSphere 7.x Privilege Label||vSphere 7.x Privilege API||vSphere 8.x Privilege Label||vSphere 8.x Privilege API|
|Profile-driven storage update||StorageProfile.Update||Update VM storage policies||StorageProfile.Update|
|Profile-driven storage view||StorageProfile.View||View VM storage policies||StorageProfile.View|
With that said, you might be asking what about those additional 5 new VM Storage Policy privileges?
Well, it turns out the rename was just minor change but there was an enhancement made to the VM Storage Policy privileges as part of a new feature that was developed by VMware Cloud on AWS (VMC-A) team. A Shared Responsibility Model is used with VMC-A, which is simliar to how AWS and other Hyperscalers operate where certain functions are managed by the provider (VMware and/or AWS) and the remainder, typically workload consumption and deployment is managed by the customer.
A really slick feature that was developed awhile back for VMC-A called Managed Storage Policy (MSP), which a special VM Storage Policy that is managed by VMware to provide SLA guarantees to customer workloads. Unlike a traditional VM Storage Policy which is statically defined and probably changes rarely, the MSP is dynamically updated by VMware based on the size of your vSphere Cluster and other SDDC properties and is updated to ensure all workloads in that cluster meets the required SLA.
The reason for this background is that the current VM Storage Policy privileges, specifically the "Update" allows a user not only to consume the VM Storage Policy, but one unintentional side affect of this privilege is that it also allows a user to modify the current VM Storage Policy but also create and delete additional VM Storage Policies.
As you can see from the screenshot above, a user with the "Update" privilege will have full access to manipulate any VM Storage Policy. I suspect the original intention of this privilege was probably design for managing (CRUD) operations for VM Storage Policies (CRUD) but unfortunately, it is also needed if you wish to apply a VM Storage Policy to a VM as an end user.
To solve this problem, additional finer-grain VM Storage Policy privileges were introduce, some of which are only applicable to a VMC-A environment but there is definitely a benefit for customers running the latest vSphere 8.x in their own environment as well as any Hyperscaler looking to provide more fine grain access control between the management of VM Storage Policies and the consumption of VM Storage Policies using the new "Apply VM storage policies" privilege.
Here is a quick summary of the five new VM Storage Policy privileges and their applicability to non-VMC-A environments:
|Privilege Label||Privilege API||Privilege Applies to VMC-A Only|
|Apply VM storage policies||StorageProfile.Apply||No|
|VM storage policies edit container mappings||StorageProfile.EditMappings||Yes|
|VM storage policies edit permissions||StorageProfile.EditPermissions||Yes|
|VM storage policies view container mappings||StorageProfile.ViewMappings||Yes|
|VM storage policies view permissions||StorageProfile.ViewPermissions||Yes|
Here are two scenarios on how you can take advantage of the new "Apply VM storage policies" privilege:
1) End users are NOT allowed to view or choose a specific VM Storage Policy but need to be able to consume a default VM Storage Policy during VM provisioning:
By leveraging the new "Apply VM storage policies" privilege, non-administrators can consume VM Storage Policies without the ability to make changes to both the existing VM Storage Policies or worse creating or deleting other VM Storage Policies.
If you have upgraded to vSphere 8.x, this is a good time to update your vSphere Roles and replace the "Update VM storage policies" with the "Apply VM storage policies" if you do not intend for users to be able to modify your existing VM Storage Policies. Furthermore, you can also control whether end users only get to consume a default VM Storage Policy as defined by you organization or provide the flexibility for users to select from a set of VM Storage Policies, which was not possible before and a users could accidentally pick the wrong VM Storage Policy due to broader permissions.
As mentioned earlier, the current vSphere 8.x documentation gap is a known issue and will be addressed. Hopefully this deeper dive along with some illustrated examples demonstrates the benefit of this new enhanced VM Storage Policy privilege that has been introduced in vSphere 8.x.