WilliamLam.com

Improved VM Storage Policy (Profile-driven storage) privileges in vSphere 8.x

by // 2 Comments

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:


Here is a a screenshot of a vSphere 8.x environment, which now actually lists seven privileges, which has lead to some additional confusion.


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.

[Read more...]

Feedback on default behavior for VM Storage Policy

by // 1 Comment

Today, the vCenter REST (vSphere Automation) APIs currently does not support the use of VM Storage Policies when relocating (vMotion, Cross Datacenter vMotion & Storage vMotion) or cloning an existing Virtual Machine. Customers have provided feedback that this is something that they would like to see get added to the current REST APIs and while this is being looked at, there were a couple of open questions from Engineering.

The following 2-question survey below is to help us understand what the "default" behavior should be when a Virtual Machine is being relocated or cloned within a vCenter Server and a VM Storage Policy is NOT specified when using the APIs. The reason for this is that our existing APIs for relocate and clone today are very flexible and not everything needs to be specified as part of the relocate or clone API specification. However, due to this flexibility, you may observe different behaviors and we would like to understand what the default behavior should be when some of these paraemters are not specified. In the case where you want to be explicit, you can always specify the VM Storage Policy, but the survey is to understand when it is not specified.

Survey: https://goo.gl/forms/aQjVTly2MmVHeRsp1

Thank you  for taking the time to provide your feedback, this will help us build an easy and robust API when dealing with relocate and clone operations using the vCenter REST APIs.

Minimum permissions to view VM Storage Policies

by // Leave a Comment

I saw this question from Aaron yesterday while scrolling through my Twitter timeline and after answering it, I figure I write a quick blog post about it in case this comes up in the future.

There are two specific privileges around managing VM Storage Policies: Update and View as shown in the screenshot below. If you only want to allow users to be able to see all the available VM Storage Policies that have been defined, then you just need to create a new Role with only the "View" privilege.

Secondly, it is important to note that VM Storage Policies are defined and managed at a vCenter Server level. This means that when you assign the permission, it needs to be applied at the root vCenter Server level (you do not have to propagate it down wards if you do not wish to show the rest of the vSphere Inventory). Global permissions are not required, but if you have multiple vCenter Servers which are all part of the same SSO Domain, you may want to consider this if users are allowed to login to any one of the vCenter Servers.

Once you have assigned the permission to either the user or group, then you can have them login using either the vSphere Web Client or using the SBPM APIs and you will now be able to view all defined VM Storage Policies.