WilliamLam.com

  • About
    • About
    • Privacy
  • VMware Cloud Foundation
  • VKS
  • Homelab
    • Hardware Options
    • Hardware Reviews
    • Lab Deployment Scripts
    • Nested Virtualization
    • Homelab Podcasts
  • VMware Nostalgia
  • Apple

Search Results for: vsphere MOB

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

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

An update on how to retrieve useful information from a vSphere login?

11.07.2016 by William Lam // 4 Comments

There was an internal Socialcast question today in which the answer could be found in my how to identify the origin of a vSphere login article. After responding to the question, I had realized that I wrote that article almost 6 years ago and what is even more crazy is that it is still very applicable today. The article explains how you can identify a vSphere login by enabling the "trivial" logging option in vCenter Server (extremely verbose, so please use with caution). Once enabled, you can go through the vpxd.log file and find things about a user login such as the the IP Address of the client as well as the type of vSphere interface they had used to login to whether that is using the vSphere C# Client or PowerCLI for example. Although this extracted information can be very useful, the process to retrieve this is not very ideal, especially having to increase your vCenter Server logging verbosity to the extreme which can force other more critical log events to roll over.

Given that this article written back when vSphere 4.1 was still the current release, I figure I should give the process another look to see if there was a better method in retrieving this information. While quickly browsing around the SessionManager object and specifically the UserSession property, I noticed there have been quite a few enhancements that were introduced in vSphere 5.1. It looks like you can now easily retrieve things like the User Agent, IP Address of the client as well as the number of API invocations for anyone who is currently logged into a given vSphere environment. Perhaps someone internally saw my blog post and thought it would be useful to add these properties directly into the vSphere API rather than poking around in the verbose logs 😀

To exercise these new vSphere APIs, I have create a quick PowerCLI function called Get-vSphereLogins The script will iterate through all currently logged in vSphere sessions and provide the following output: Username, IP Address, API Count & Login Time. It also excludes the current session initiating the query as well as any of the VC Extension logins. Here is a screenshot of my environment using several different vSphere API interfaces to login to my vSphere environment:

retreiving-useful-information-about-vsphere-login-0
With the information above, not only can you tell who is logging in but also where (IP Address) and most importantly how (User Agent) they are logging in. One thing to be aware of is that the User Agent is not always populated and even if it is, it may not provide you with enough information on the specific interface a given user is logging in from. For example, it looks like a script written using the vSphere SDK for Python does not actually set the User Agent, so it is empty.

Here is an updated table using some of the latest vSphere interfaces to log into a vSphere 6.0 Update 2 environment and their respective observed User Agents:

Interface User Agent
vSphere C# Client VMware vSphere Client/6.0.0
vSphere Web Client VMware vim-java 1.0
vSphere MOB Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_1) AppleWebKit/537.36 (KHTML like Gecko) Chrome/54.0.2840.71 Safari/537.36
PowerCLI PowerCLI/6.5.0
vSphere SDK for Perl VI Perl
vSphere SDK for Ruby (rbvmomi) Ruby
vSphere SDK for Python (pyvmomi) None

Note: In vSphere 6.5, the User Agent that is returned for the vSphere Web Client session looks to be using web-client/6.5.0

Finally, saving the best for last. The VMware Engineer(s) not only added these new properties into the vSphere API, but they have also made them readily available using the vSphere Web Client. To view all the session information, navigate to your vCenter Server instance and under Manage->Sessions you can get the exact same view as using the vSphere API. By default, the IP Address, User Agent & API Invocations are hidden by default. You just need to right click on the table header and add those additional field as shown in the screenshot below.

retreiving-useful-information-about-vsphere-login-1
Longer term, it would be great to see that each of the "official" VMware CLI/SDKs as well as other interfaces can uniquely identify themselves with a well defined string. This not only helps with understanding the types of tools customers are using but also helps with any types of internal audits customers may require. If you think this would be useful to have, please feel free to leave a comment or any other things you feel would be useful to include.

Categories // Automation Tags // PowerCLI, pyVmomi, rbvmomi, session, user agent, vSphere API, vsphere client, vSphere MOB, vSphere SDK, vsphere sdk for perl, vsphere web client

  • « Previous Page
  • 1
  • …
  • 7
  • 8
  • 9
  • 10
  • 11
  • …
  • 36
  • 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

  • Ultimate Lab Resource for VCF 9.0 06/25/2025
  • VMware Cloud Foundation (VCF) on ASUS NUC 15 Pro (Cyber Canyon) 06/25/2025
  • VMware Cloud Foundation (VCF) on Minisforum MS-A2 06/25/2025
  • VCF 9.0 Offline Depot using Synology 06/25/2025
  • Deploying VCF 9.0 on a single ESXi host? 06/24/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...