WilliamLam.com

  • About
    • About
    • Privacy
  • VMware Cloud Foundation
  • VKS
  • Homelab
    • Resources
    • Nested Virtualization
  • VMware Nostalgia
  • Apple

Automating vSphere Global Permissions with PowerCLI

03.06.2017 by William Lam // 6 Comments

vSphere Global Permissions was first introduced in vSphere 6.0, which provides a simple and consistent method for assigning permissions for individual users and/or groups across multiple vCenter Servers joined to the same vCenter Single Sign-On (SSO) Domain. Global permissions works in the same way as traditional vSphere Permissions, but rather than assigning a permission to a specific entity, the association is applied at the root level of the vCenter Server.

The other added benefit for customers who are using vCenter's Enhanced Linked Mode (ELM), the global permission will be available to all vCenter Servers which are part of that ELM configuration. Without global permissions, a customer would have to create and assign a new permission to each and every vCenter Server and ensure that they all match which can be very error prone.

One downside to using vSphere Global Permissions today is that there is currently not a public API for those wanting to automate the creation and deletion of global permissions. However, as quick workaround, I have found a way in which you can automate the global permission management using the vSphere MOB which would allow us to use PowerCLI or any other vSphere Automation toolkit for that matter.

UPDATE (04/07/25) - See this updated blog post for listing vSphere Global Permissions.

I have created a simple PowerShell script called GlobalPermissions.ps1 which contains two functions New-GlobalPermission and Remove-GlobalPermission which hopefully is self explanatory in what they do.

To create a new vSphere Global Permission, the function requires the following 6 parameters:

  • vc_server - Hostname or IP of the vCenter Server
  • vc_username - The VC username
  • vc_password - The VC password
  • vc_user - The vSphere User to assign the permission to
  • vc_role_id - The Role ID associated with the vSphere Role within vCenter Server (more on this later)
  • propagate - true or false on whether to propagate the permission

To retrieve the vc_role_id, you simply need access to a vCenter Server and run the following snippet along with the name of the vSphere Role to get its ID. In the example below, the Administrator role is called "Admin" using the vSphere API and the following will return the ID:

(Get-VIRole -Name Admin).ExtensionData.RoleId

Once you have retrieved the vSphere Role ID, here is an example of running the New-GlobalPermission function:

$vc_server = "192.168.1.51"
$vc_username = "*protected email*"
$vc_password = "VMware1!"
$vc_role_id = "-1"
$vc_user = "VGHETTO\lamw"
$propagate = "true"
New-GlobalPermission -vc_server $vc_server -vc_username $vc_username -vc_password $vc_password -vc_user $vc_user -vc_role_id $vc_role_id -propagate $propagate

If the operation was successful, you should be able to login using the vSphere Web Client and refresh the global permissions view and you should see the new permission assignment as shown in the screenshot below.

To remove a global permission, you only need to provide the vCenter Server, its credentials and the user permission you wish to remove:

Remove-GlobalPermission -vc_server $vc_server -vc_username $vc_username -vc_password $vc_password -vc_user $vc_user

Categories // Automation, PowerCLI Tags // global permission, mob, PowerCLI

Exploring new VCSA VAMI API w/PowerCLI: Part 9

03.02.2017 by William Lam // Leave a Comment

In Part 9, we were initially going to cover the new backup and restore capability that was introduced in vSphere 6.5 for the VCSA. However, it looks like Brian Graf has already created an awesome PowerCLI module (Backup-VCSA.psm1) that can be used to backup the VCSA, which you can find more details here.

While going through the VAMI APIs for the backup feature, I did notice there was one interesting backup VAMI API that Brian may not have looked at, at least I did not see a function consuming this API. Prior to initiating a backup for either a VCSA or PSC, you can query the expected size of the backup. This information can be pretty helpful beyond just for backups, but understanding the size of your system at any point in time.

VAMI UI Area of Focus

The backup and restore feature for the VCSA is located in the VAMI UI, but there is not a UI for retrieving the current expected backup size.

VAMI APIs Used

  • GET /appliance/recovery/backup/parts

PowerCLI Function

  • Get-VAMIBackupSize

Sample Output

The output is pretty straight forward, it provides the total expected backup size (MB) as well as the breakdown of the total size into "configuration" data and the "Stats, Events, Alarms and Tasks" (SEAT) data.


With this new API, you can now easily see how large your vCenter Server Database is and take appropriate action such as truncating the data or reducing the retention period which can especially help with the performance of vCenter Server as well as the time it takes during upgrades.

  • Exploring new VCSA VAMI API w/PowerCLI: Part 1
  • Exploring new VCSA VAMI API w/PowerCLI: Part 2
  • Exploring new VCSA VAMI API w/PowerCLI: Part 3
  • Exploring new VCSA VAMI API w/PowerCLI: Part 4
  • Exploring new VCSA VAMI API w/PowerCLI: Part 5
  • Exploring new VCSA VAMI API w/PowerCLI: Part 6
  • Exploring new VCSA VAMI API w/PowerCLI: Part 7
  • Exploring new VCSA VAMI API w/PowerCLI: Part 8
  • Exploring new VCSA VAMI API w/PowerCLI: Part 9
  • Exploring new VCSA VAMI API w/PowerCLI: Part 10

Categories // Automation, PowerCLI, vSphere 6.5 Tags // PowerCLI, vami, vcenter server appliance, vSphere 6.5

Cross vCenter Server operations (clone / migrate) between versions of vSphere 6.x

02.27.2017 by William Lam // 7 Comments

When cross vCenter Server operations such as clone and migrate was first introduced in vSphere 6.0, it required that both the source and destination vCenter Server (includes ESXi hosts) to be running the same vSphere version. With the release of vSphere 6.5, this base requirement still holds true (e.g. vSphere 6.5 for both source and destination), especially when performing these operations using the vSphere Web Client where mixed-vSphere versions is not supported outside of a rolling upgrade.

Having said that, it is possible and supported to clone or migrate a VM across different versions of vSphere 6.x, for example a vSphere 6.5 and a vSphere 6.0 Update 3 environment. This can be accomplished by performing a xVC-vMotion or xVC-Clone operation using the vSphere API. For the the xVC-vMotion use case, I have extensively written about it here and here and with PowerCLI 6.5r1, the Move-VM cmdlet has even been updated based on my feedback to support this capability natively. Furthermore, you can even perform these operations across completely different vCenter Single Sign-On Domains, which enables a new level of mobility for your VMs and access to resources of independently deployed vCenter Server instances.

UPDATE (11/01/17) - The following VMware KB 2106952 has just been updated to reflect what is officially supported in terms of Cross vCenter Operations ( Clone / Migrate) across different versions of vSphere. The matrix in the KB reflects what has been tested by Engineering and one thing you may notice is that Cross vCenter vMotion/Clone from vSphere 6.x to vSphere 6.5 is only supported when running at least vSphere 6.0 Update 3. After speaking with the PM, the reason for this change is that pre-vSphere 6.0 Update 3, there were no pre-checks in the code to prevent Cross vCenter Operations for un-supported target hosts such as ESXi 5.5, which could lead to poor user experience as well as undefined failure scenarios. In addition, vSphere 6.0 Update 3 also includes additional enhancements to properly clean up failed provisioning operations which will make Cross vCenter Operations much more robust. Due to these reasons, though it is possible to perform Cross vCenter vMotion from earlier versions, it will not be officially supported. I have also updated my summarized table below to reflect what is in the VMware KB, but please use the KB as your official source of truth for what VMware supports.

To help make sense of the different combinations of vMotions and cloning operations, below are a few tables to help outline what is possible and supported today.

vMotion

Source vCenter Server Destination vCenter Server Supported UI or API
vSphere 6.0 vSphere 6.0 Yes UI and API
vSphere 6.x (pre 6.0 Update 3) vSphere 6.5 Possible but Not Supported N/A
vSphere 6.0 Update 3 vSphere 6.5 Yes API
vSphere 6.5 vSphere 6.5+ Yes UI and API
vSphere 6.5 vSphere 6.x No No
vSphere 6.5+ VMware Cloud on AWS Yes UI and API
VMware Cloud on AWS vSphere 6.5+ Yes UI and API

Cold Migrate

Source vCenter Server Destination vCenter Server Supported UI or API
vSphere 6.0 vSphere 6.0 Yes UI and API
vSphere 6.x (pre 6.0 Update 3) vSphere 6.5 Possible but Not Supported API
vSphere 6.0 Update 3 vSphere 6.5 Yes API
vSphere 6.5 vSphere 6.5 Yes UI and API
vSphere 6.5 vSphere 6.x No No
vSphere 6.5+ VMware Cloud on AWS Yes UI and API
VMware Cloud on AWS vSphere 6.5+ Yes UI and API

Clone

Source vCenter Server Destination vCenter Server Supported  UI or API
vSphere 6.0 vSphere 6.0 Yes UI and  API
vSphere 6.x (pre 6.0 Update 3) vSphere 6.5 No N/A
vSphere 6.0 Update 3 vSphere 6.5 No N/A
vSphere 6.5 vSphere 6.5+ Yes UI and API
vSphere 6.5 vSphere 6.x No N/A
vSphere 6.5+ VMware Cloud on AWS Yes UI and API
VMware Cloud on AWS vSphere 6.5+ Yes UI and API

Virtual Networking Migration

Source Type Destination Type Supported
VDS VDS Yes
VDS VSS No
VSS VSS Yes
VSS VDS Yes

Note1: vMotioning and/or cloning of VMs which uses the new vSphere Encryption feature introduced in vSphere 6.5 is not supported.

Note2: "Compute" only xVC-vMotion insufficient space issue has now been resolved with vSphere 6.0 Update 3, see this post here for more details.

Note3: xVC-vMotion is not supported on 3rd party switches as we can not checkpoint the switching state.

Here are some additional xVC-vMotion and vMotion articles that may also useful to be aware of:

  • Are Affinity/Anti-Affinity rules preserved during Cross vCenter vMotion (xVC-vMotion)?
  • Duplicate MAC Address concerns with xVC-vMotion in vSphere 6.0
  • Network Compatibility Checks During vMotion Between vCenter Server Instances
  • Auditing vMotion Migrations

Categories // Automation, vSphere 6.0, vSphere 6.5 Tags // Cross vMotion, ExVC-vMotion, vSphere 6.0, vSphere 6.5, vSphere API, xVC-vMotion

  • « Previous Page
  • 1
  • …
  • 144
  • 145
  • 146
  • 147
  • 148
  • …
  • 224
  • Next Page »

Search

Thank Author

Author

William is Distinguished Platform Engineering Architect in the VMware Cloud Foundation (VCF) Division at Broadcom. His primary focus is helping customers and partners build, run and operate a modern Private Cloud using the VMware Cloud Foundation (VCF) platform.

Connect

  • Bluesky
  • Email
  • GitHub
  • LinkedIn
  • Mastodon
  • Reddit
  • RSS
  • Twitter
  • Vimeo

Recent

  • Programmatically accessing the Broadcom Compatibility Guide (BCG) 05/06/2025
  • Quick Tip - Validating Broadcom Download Token  05/01/2025
  • Supported chipsets for the USB Network Native Driver for ESXi Fling 04/23/2025
  • vCenter Identity Federation with Authelia 04/16/2025
  • vCenter Server Identity Federation with Kanidm 04/10/2025

Advertisment

Privacy & Cookies: This site uses cookies. By continuing to use this website, you agree to their use.
To find out more, including how to control cookies, see here: Cookie Policy

Copyright WilliamLam.com © 2025

 

Loading Comments...