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

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 // ESXi, PowerCLI, vSphere Tags // guest operations, nested, nested virtualization, vix, vix api, vmware tools

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

Automating installation of VMware Tools for Mac OS X

06.18.2015 by William Lam // 1 Comment

After publishing my recent article on automating the silent installation of VMware Tools for Linux guestOSes, I received a similar question regarding Mac OS X guests and whether the existing script would also apply. The answer is no since Mac OS X packages differ from the Linux installres, but it is possible to automate the installation of VMware Tools for Mac OS X guests.

After quickly looking into this, I realized there are actually several options that are available to customers and it would depend on how you would like to install VMware Tools and what platform you are running your Mac OS X guests on. I will share a couple of options which also includes existing solutions that have already been developed. At the end of the day, the choice will ultimately be up to the administrator on how he/she would like to proceed.

[Read more...]

Categories // Apple, ESXi, vSphere Tags // apple, darwin.iso, ESXi, osx, vmware tools

  • « Previous Page
  • 1
  • …
  • 73
  • 74
  • 75
  • 76
  • 77
  • …
  • 110
  • 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

  • Quick Tip: How to Identify Which Kubernetes Cluster Owns a vSphere Container Volume (PV) 06/25/2026
  • What Host Lifecycle Operations Are Available after Importing vCenter into VCF 9.x Fleet? 06/24/2026
  • VCF 9.1 - Enabling High Availability for a Small VCF Management Services (VCFMS) Deployment 06/22/2026
  • Clarifying Minimum Required ESX Hosts for VCF Deployments 06/18/2026
  • VCF 9.1 - Auditing VCF Management Services (VCFMS) IP Pool Usage  06/17/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...