WilliamLam.com

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

Quick Tip - Determining the vCenter Server OS platform (Windows or VCSA) using vSphere API

06.25.2015 by William Lam // Leave a Comment

The vSphere API is an extensively rich interface for being able to extract all sorts of useful information about your vSphere infrastructure. One useful trick that may come in handy for those requiring to perform operations directly against the vCenter Server guestOS itself is to figure out whether you are connecting to a Windows vCenter Server or the vCenter Server Appliance (VCSA)? Lets say you wish to automate the deployment of the recently released VSAN 6.0 Health Check Plugin and the process to install the plugin will differ between Windows vCenter Server and the VCSA, so it would be ideal if you can easily distinguish between the two

A simplistic solution would be to quickly test for something that would exist in either Windows or Linux, but what if you wanted to perform these operations using the vSphere API and the Guest Operations API to execute the commands within the guests? Well, luckily the vSphere API actually provides this information when connecting to a vCenter Server API endpoint and you can tell if you are connecting to a Windows vCenter Server or the VCSA.

To determine the guestOS type for the vCenter Server you are connecting to, there is a property called osType which you can query when you first connect. Below is a quick PowerCLI snippet for accessing this property, you can also use a variety of other vSphere SDKs to extract this property.

$server = Connect-VIServer -Server reflex.primp-industries.com

$server.ExtensionData.Content.About

Disconnect-VIServer -Server $server -Confirm:$false

The osType property for the VCSA is linux-x64

vcenter-server-os-platform-0
The osType property for vCenter Server for Windows is win32-x64

vcenter-server-os-platform-1

Categories // vSphere Tags // PowerCLI, vCenter Server, vcenter server appliance, VCSA, vcva, vSphere API

Using latest PowerActions 1.5.0 to issue VMFS UNMAP API in vSphere 6.0 Web Client

06.22.2015 by William Lam // 4 Comments

Last week, the popular PowerActions Fling was updated to version 1.5.0 which now finally adds support for vSphere 6.0. PowerActions is a vSphere Web Client Plugin that allows administrators to easily execute PowerCLI scripts against inventory objects within the vSphere Web Client. This is a very powerful capability that PowerActions is providing and allows users to easily extend new and custom operations that may not be available within the vSphere Web Client. One such example is being able to easily issue a VMFS UNAMP which in vSphere 5.5 was only available through the use of ESXCLI, I actually demonstrated how easy it is to provide this capability using PowerActions which you can read more about here.

With the release of vSphere 6.0, we now have the ability to issue a VMFS UNMAP using the vSphere API which I have blogged about here among other new vSphere 6.0 APIs. Given that PowerActions now supports vSphere 6.0, I figured this would be a good opportunity to take advantage of the new vSphere 6.0 API using the updated version of PowerActions. I have created a new PowerCLI script called Issue UNMAP 2.0 on Datastore.ps1 which now uses the new UnmapVmfsVolumeEx_Task vSphere API to perform the VMFS UNMAP. I have also submitted a new pull request for this example to Alan Renouf's PowerActions Github repository.

Here is a screenshot of my running the new VMFS UNMAP PowerActions operation against one of my vSphere Datastores and you can that it successfully completed in the Recent Tasks bar.

poweractions-vmfs-unmap
In addition to the new VMFS UNAMP operation that can be added as a PowerAction, here are just a few other examples of new vSphere 6.0 capabilities that you can easily extend into a PowerAction:

  • Perform XvC-vMotion (Migrating a VM between two different vCenter Servers which are NOT part of the same SSO Domain)
  • Configure per-VMDK IOPS reservations
  • Send an NMI request to a VM using the new vSphere 6.0 API described here

I am personally excited for the future and potential of PowerActions and I hope to see the PowerActions framework extend beyond just PowerCLI and support other scripting languages. I think this will be a very powerful capability that the vSphere Web Client can offer to our administrators, operators and developers.

Categories // Uncategorized Tags // PowerCLI, unmap, vSphere 6.0, vSphere API, vsphere web client

Retrieving statistics for a Distributed Virtual Port using the vSphere API & PowerCLI

06.01.2015 by William Lam // 2 Comments

Over the weekend I received an email from a fellow colleague over in the NSBU who was interested in retrieving statistics on an individual Distributed Virtual Port using the vSphere API and had asked if I had done this before. Although I have written about using the vSphere API to access various properties of a Distributed Virtual Switch (here & here) and migrating from a Virtual Standard Switch (VSS) to Distributed Virtual Switch (VDS) and from a VDS back to VSS (here & here), I have not done a whole lot with the vSphere API with regards to individual Distributed Virtual Ports.

Having said that, with the easy to use PowerCLI Distributed Virtual Switch cmdlets being available, it is actually not too difficult to retrieve this information using the vSphere API. For those of you who have not worked with a Distributed Virtual Switch before, to view the statistics of an individual Distributed Virtual Port, you must drill down into a specific Distributed Virtual Portgroup which you can find using either the vSphere Web/C# Client. Below is a screenshot from my vSphere Web Client.

distributed-virtual-port-stats-0
To retrieve information on a Distributed Virtual Port using the vSphere API, you can refer to the DistributedVirtualPort property. Within this object, there is a state property which you can then drill down further to retrieve statistics using the stat property. If you would like to be able to pull other properties as shown in the screenshot, you can use the runtimeInfo property which provides additional information on the Distributed Virtual Port such as connected entity, MAC Address, VLAN ID, state, etc.

The following two PowerCLI VDS cmdlets: Get-VDPortgroup & Get-VDPort will help us retrieve the information we are looking. However, out of the box these cmdlets do not support pulling statistics for a Distributed Virtual Port. To do so, we will need to access the ExtensionData property which will allows us to access the underlying vSphere API from the PowerCLI object.

Below is a simple PowerCLI script which connects to a vCenter Server and retrieves a specific Distributed Virtual Portgroup (dvPg) that we are interested in using the Get-VDPortgroup cmdlet. Once we have the dvPg, we can then identify a specific Distributed Virtual Port (dvP) by using the Get-VDPort and passing in the dvPg from the previous command as well as the specific port by using the -key property. From here, we can then access a few properties from the dvP and most importantly, the statistics which we were originally interested in. In the example below, I am displaying the entire "stat" property, but you can easily filter out the specific stats you care about.

$server = Connect-VIServer -Server reflex.primp-industries.com

# Retrieve a Distributed Portgroup
$vdportgroup = Get-VDPortgroup -Name dv-vlan333

# Retrieve a specific Distributed Virtual Port from the Distributed Portgroup using the "key" property
$vdport = Get-VDPort -VDPortgroup $vdportgroup -Key 4

# Sample Distributed Virtual Port properties
Write-Host "Link Up: " $vdport.ExtensionData.State.RuntimeInfo.Linkup
Write-Host "Connectee: " $vdport.ExtensionData.State.RuntimeInfo.LinkPeer
Write-Host "Runtime MAC Address: " $vdport.ExtensionData.State.RuntimeInfo.macAddress

# Distributed Virtual Port Stats
$vdport.ExtensionData.State.Stats

Disconnect-VIServer -Server $server -Confirm:$false

Here is an example of the output from the script above and we can see that Distributed Virtual Port "4" matches to what we see in the vSphere Web Client screenshot.
distributed-virtual-port-stats-1

Categories // ESXi, PowerCLI, vSphere Tags // distributed portgroup, distributed virtual port, distributed virtual switch, dvs, PowerCLI, vds, vSphere API

  • « Previous Page
  • 1
  • …
  • 38
  • 39
  • 40
  • 41
  • 42
  • …
  • 44
  • 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
  • Reddit
  • RSS
  • Twitter
  • Vimeo

Recent

  • VCF Agentic AI Hub (Code Assist) MCP Server Fling 10/05/2026
  • Automate Inventory of vSphere Supervisor Clusters & vSphere Kubernetes Service (VKS) Guest Clusters 10/02/2026
  • VCF 9.1.1 - OCuLink External Graphics (eGPU) Dock with integrated PSU for GPU Passthrough with VKS 10/01/2026
  • VCF 9.1.1 - Single ESX Host for VCF Fleet, VCF Workload Domain or VCF Cluster 09/30/2026
  • Bypassing Minimum Unique Flows & Metric Collection Period for vDefend Security Services Platform (SSP) 5.2 Lab Deployments 09/28/2026
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 © 2026

Loading Comments...