WilliamLam.com

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

Using PowerCLI to invoke Guest Operations API to a Nested ESXi VM

07.14.2015 by William Lam // 1 Comment

In my opinion, the Guest Operations API in vSphere is still one of the most powerful Virtual Machine capabilities that is available to vSphere Administrators and anyone else who integrates with the vSphere Platform. The Guest Operations API allows users to perform guest operations (running commands, transferring files, etc) directly within the guestOS as if you were logged in. Valid guest credentials are still required and once authenticated, the operations are then proxied through VMware Tools. Networking is not even required which makes this a handy feature for troubleshooting and can even extend into application level provisioning through a single API.

Obviously, I am a huge fan of this capability and have used it myself on more than one occasion. However, one limitation that I discovered awhile back when using the Guest Operations API with Nested ESXi VMs is that it threw some very strange memory related errors. It was only recently did I find out that there was a known issue with the VMware Tools for Nested ESXi, both the installable VIB and the pre-installed version in ESXi 6.0 on how the guest operations are executed. The good news is that for now, there is a simple workaround that can be applied when using the Guest Operations API.

You will need to add the following option, which runs the command under a specific resource group in the ESXi Shell:

'++group=host/vim/tmp'

Here is an example if I were to run the 'echo' command:

/bin/echo '++group=host/vim/tmp' "hello world"

A more interesting example would be to issue ESXCLI commands using the Guest Operations API, perhaps configuring the welcome message?

/bin/python '++group=host/vim/tmp' '/bin/esxcli.py system welcomemsg set -m "vGhetto Was Here"'

Notice, we need to pass in the resource group command to the "python" binary versus ESXCLI binary. The reason for this is that /bin/esxcli is really just a symlink to /bin/esxcli.py which is just a Python wrapper. The actual command being launched is the python interpreter and the arguments to the command is /bin/esxcli.py and the ESXCLI arguments itself.

For those who prefer to consume the Guest Operations API without having to directly use the vSphere API, you can use PowerCLI and use the Invoke-VMScript cmdlet. The problem with that is due to the way the cmdlet has been abstracted, the necessary underlying API details can not be accessed due to certain assumed defaults which can not be overridden or extended. This is a general problem that I have seen in more than one occasion where the abstraction is to make the consumption of the API simpler but in certain cases, it can also inhibit the use of the underlying API feature.

In this case, we will actually need to call into the vSphere API and using PowerCLI as an example, I have created a script called runGuestOpsInNestedESXiVM.ps1 which implements the specific Guest Operations APIs to issue commands to a Nested ESXi VM.

Here is an example of running the script and configuring the welcome message using ESXCLI:

guest_operations_api_nested_esxi

Categories // Automation, ESXi, PowerCLI, vSphere, vSphere 6.0 Tags // guest operations, nested, nested virtualization, vix, vix api, vmware tools

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 // Automation, ESXi, PowerCLI, vSphere Tags // distributed portgroup, distributed virtual port, distributed virtual switch, dvs, PowerCLI, vds, vSphere API

Automate the reverse, migrating from vSphere Distributed Switch to Virtual Standard Switch using PowerCLI 5.5

11.05.2013 by William Lam // 14 Comments

Last week I demonstrated how you can easily leverage the new PowerCLI 5.5 VDS cmdlets to migrate from a VSS (Virtual Standard Switch) to a VDS (vSphere Distributed Switch). During the development of the script, I needed a way to easily jump back and fourth between VSS->VDS and VDS->VSS and I wanted to automate this so I did not have to use the UI to reset my environment.

I initially thought this was not possible after playing around with a couple of the cmdlets but thanks to Kamen, a PowerCLI Engineer who was able to provide me with the necessary information to create a reverse migration script going from VDS to VSS.

Here is what my lab environment looks like which includes three ESXi hosts connected to a VDS called "VDS-01" which is backed by 4 pNICSs. The VDS contains 3 VMkernel interfaces and here are their respective DVPortgroup names: Management Network, Storage Network and vMotion Network.

On each ESXi host, there is an already created VSS called "vSwitch0". If one is not created or if you decide to name it something differently, then you will need to modify the script. Here is a quick screenshot of what that looks like

The PowerCLI example script below uses the Add-VirtualSwitchPhysicalNetworkAdapter cmdlet which accepts a list of pNICs, VMkernel interfaces and the portgroups to migrate from VDS to VSS. The order in which the VMkernel and portgroups are specified is critically important as they will be assigned based on the provided ordering. The script also create the necessary portgroups on the VSS which of course can be modified based on your environment. Once the migration has been completed, it will then use the Remove-VDSwitchVMHost cmdlet to remove the ESXi hosts from the VDS.

Disclaimer: Please ensure you test this script in a development/test lab before using it in a production environment.

Connect-VIServer -Server vcenter55-1.primp-industries.com -User *protected email* -Pass vmware</b></i>

# ESXi hosts to migrate from VSS-&gt;VDS
$vmhost_array = @("vesxi55-1.primp-industries.com","vesxi55-2.primp-industries.com","vesxi55-3.primp-industries.com")

# VDS to migrate from
$vds_name = "VDS-01"
$vds = Get-VDSwitch -Name $vds_name

# VSS to migrate to
$vss_name = "vSwitch0"

# Name of portgroups to create on VSS
$mgmt_name = "Management Network"
$storage_name = "Storage Network"
$vmotion_name = "vMotion Network"

foreach ($vmhost in $vmhost_array) {
Write-Host "`nProcessing" $vmhost

# pNICs to migrate to VSS
Write-Host "Retrieving pNIC info for vmnic0,vmnic1,vmnic2,vmnic3"
$vmnic0 = Get-VMHostNetworkAdapter -VMHost $vmhost -Name "vmnic0"
$vmnic1 = Get-VMHostNetworkAdapter -VMHost $vmhost -Name "vmnic1"
$vmnic2 = Get-VMHostNetworkAdapter -VMHost $vmhost -Name "vmnic2"
$vmnic3 = Get-VMHostNetworkAdapter -VMHost $vmhost -Name "vmnic3"

# Array of pNICs to migrate to VSS
Write-Host "Creating pNIC array"
$pnic_array = @($vmnic0,$vmnic1,$vmnic2,$vmnic3)

# vSwitch to migrate to
$vss = Get-VMHost -Name $vmhost | Get-VirtualSwitch -Name $vss_name

# Create destination portgroups
Write-Host "`Creating" $mgmt_name "portrgroup on" $vss_name
$mgmt_pg = New-VirtualPortGroup -VirtualSwitch $vss -Name $mgmt_name

Write-Host "`Creating" $storage_name "Network portrgroup on" $vss_name
$storage_pg = New-VirtualPortGroup -VirtualSwitch $vss -Name $storage_name

Write-Host "`Creating" $vmotion_name "portrgroup on" $vss_name
$vmotion_pg = New-VirtualPortGroup -VirtualSwitch $vss -Name $vmotion_name

# Array of portgroups to map VMkernel interfaces (order matters!)
Write-Host "Creating portgroup array"
$pg_array = @($mgmt_pg,$storage_pg,$vmotion_pg)

# VMkernel interfaces to migrate to VSS
Write-Host "`Retrieving VMkernel interface details for vmk0,vmk1,vmk2"
$mgmt_vmk = Get-VMHostNetworkAdapter -VMHost $vmhost -Name "vmk0"
$storage_vmk = Get-VMHostNetworkAdapter -VMHost $vmhost -Name "vmk1"
$vmotion_vmk = Get-VMHostNetworkAdapter -VMHost $vmhost -Name "vmk2"

# Array of VMkernel interfaces to migrate to VSS (order matters!)
Write-Host "Creating VMkernel interface array"
$vmk_array = @($mgmt_vmk,$storage_vmk,$vmotion_vmk)

# Perform the migration
Write-Host "Migrating from" $vds_name "to" $vss_name"`n"
Add-VirtualSwitchPhysicalNetworkAdapter -VirtualSwitch $vss -VMHostPhysicalNic $pnic_array -VMHostVirtualNic $vmk_array -VirtualNicPortgroup $pg_array  -Confirm:$false
}

Write-Host "`nRemoving" $vmhost_array "from" $vds_name
$vds | Remove-VDSwitchVMHost -VMHost $vmhost_array -Confirm:$false

<i><b>Disconnect-VIServer -Server $global:DefaultVIServers -Force -Confirm:$false

Here is a screenshot of the script executing:

Categories // Automation, PowerCLI Tags // distributed virtual switch, migration, PowerCLI, vds, vSphere 5.5, vss

  • « Previous Page
  • 1
  • …
  • 53
  • 54
  • 55
  • 56
  • 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...