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 the vSphere API to remotely collect ESXi configuration file (esx.conf)

06.23.2016 by William Lam // 9 Comments

Last week we took a look at two new Automated solutions here and here that allows us to leverage vCenter Server and the vSphere APIs to remotely extract information that historically required logging in directly into an ESXi host. While working on the two scripts, I was reminded of another use that could also be really useful which builds on top of some information that I had shared back in 2012. ESXi provides a very basic file manipulation capability that is exposed as a simple HTTPS-based interface.

Here is a quick recap of the three URLs which can be accessed by opening a browser and logging into the ESXi host:

  • https://esxi-1.primp-industries.com/host
  • https://esxi-1.primp-industries.com/folder
  • https://esxi-1.primp-industries.com/tmp

For the purpose of this article, we will be focusing on the first url endpoint /host and below is an example screenshot on some of the configuration files (46 in total) that you would be able to access using this interface.

vsphere-api-to-remotely-collect-esx-conf
One of the available ESXi configuration files that you access is the esx.conf file directly where it might be useful to periodically capture the state of this file for either auditing or troubleshooting purposes.

Note: Although esx.conf does contain some amount of the ESXi configurations, it does not represent the full state of the ESXi host. If you wish to perform periodic full backups of your ESXi host (which includes esx.conf by default among other files), there is a vSphere API for this by using the HostFirmwareSystem and the BackupFirmwareConfiguration() method.

Applying the same technique as I have described here, we can easily retrieve the esx.conf for a specific ESXi host being managed by vCenter Server without needing directly login to the ESXi host or worse connecting via SSH. I have created a PowerCLI script called Get-Esxconf.ps1 which just accepts a VMHost object.

Here is an example of how you would use the function and screenshot below of the output:

$esxConf = Get-VMHost -Name "esxi-1" | Get-Esxconf

vsphere-api-to-access-esxconf
If you are interested in a specific key within the esx.conf configuration file, we further process the output. The following snippet below searches for the following key /system/uuid and will return the value as it iterates through the esx.conf output.

$esxConf = Get-VMHost -Name "esxi-1" | Get-Esxconf

$keyToSearchFor = "/system/uuid"

foreach ($line in $esxConf.Split("`n")) {
    $data = $line.split("=").trim().replace('"',"")
    if($data[0] -eq $keyToSearchFor) {
        Write-Host "Key:" $keyToSearchFor 
        write-Host "Value:" $data[1]
    }
}

Hopefully this gave you an idea of just one of the many use cases that can now be enabled through the use of the vSphere API and this ESXi interface. Here are just a few other use cases that I can think of on the top of my mind that could come in handy:

  • Managing ESXi SSH public/private keys, we have mostly been using httpGet, but you can also use an httpPut to upload these files without needing to go to each and every ESXi host
  • Replacing Custom SSL Certificates if you are not using VMCA, you can also use an httpPut request to upload these files (you will need to restart hostd or reboot the host for the new SSL Certificates to go into effect)
  • Quickly access the vpxa.cfg (vCenter Server agent) configuration file for troubleshooting purposes

Categories // Automation, ESXi, PowerCLI, vSphere Tags // esx.conf, PowerCLI, vCenter Server, vSphere API

Using the vSphere API to remotely collect ESXi esxcfg-info

06.15.2016 by William Lam // 7 Comments

Using the same technique as I have described here, you can now also use the vSphere API to connect to vCenter Server to remotely collect esxcfg-info from ESXi hosts without having to SSH'ing to each and every single host. Historically, the esxcfg-* commands were only available in the classic ESX Service Console (COS) and the ESXi Shell. As part of the ESXi transition, VMware has converted all the commands over to the vSphere API which means that you no longer needed to run those local CLIs commands to manage or configure your ESXi hosts like you used to with classic ESX.

The only exception that still exists today is the esxcfg-info command, which still contains a lot of useful information, for some of which is not currently in the vSphere API today. Similiar to the vm-support.cgi script, there is also an esxcfg-info.cgi script which I had blogged about here back in 2011. To output the esxcfg-info, simply open a web browser and specify the following URL with the Hostname/IP Address of your ESXi host:

https://esxi-1.primp-industries.com/cgi-bin/esxcfg-info.cgi

Once you have authenticated with a valid user, you will see that the output matches the output if you were to manually run esxcfg-info command on the ESXi Shell.

esxcfg-info-regular-output
Instead of the raw output that you are all probably familiar with, you can also format the output using XML simply by appending ?xml to the end of the URL:

https://esxi-1.primp-industries.com/cgi-bin/esxcfg-info.cgi?xml

esxcfg-info-xml-output
With the second formatted option, we can now easily retrieve the result and store that into an XML object for processing using any one of our favorite scripting/programming languages. In the previous article, I demonstrated the use of the vSphere API method AcquireGenericServiceTicket() using a pyvmomi (vSphere SDK for Python) script. In this example, I will demonstrate the exact same use of the vSphere API but now leveraging PowerCLI. I have created a script called Get-Esxcfginfo.ps1 which connects to a vCenter Server and requests a session ticket to a specific ESXi host's esxcfg-info.cgi URL and that will then return us a one time HTTP request to connect to the ESXi host to retrieve the requested information.

Here is an example on how to use the command which will return the XML output which would then require further processing of the XML:

$xmlResult = Get-VMHost -Name "192.168.1.190" | Get-Esxcfginfo

I have also included an example of how to parse the XML return in the script itself. As you can see from the screenshot below, I am extracting the Device Name, Vendor Name & Vendor ID from the esxcfg-info output.

vsphere-api-to-access-esxcfg-info

Pretty cool huh? Stay tuned for one more blog post which I will show you another way in which you can make use of this vSphere API!

Categories // Automation, ESXi, PowerCLI, vSphere Tags // esxcfg-info, ESXi, PowerCLI, vCenter Server, vSphere API

Automating Cross vCenter vMotion (xVC-vMotion) between the same & different SSO Domain

05.26.2016 by William Lam // 79 Comments

In the last couple of months, I have noticed an increase in customer interests in using the Cross vCenter vMotion (xVC-vMotion) capability that was introduced back in vSphere 6.0. In my opinion, I still think this is probably one of the coolest features of that release. There is no longer the limitation of restricting your Virtual Machine mobility from within a single vCenter Server, but you can now live migrate a running VM across different vCenter Servers.

The primary method to start a xVC-vMotion is by using the vSphere Web Client which requires your vCenter Servers Servers to be part of the same SSO Domain and will automatically enable the new Enhanced Linked Mode (ELM) feature. ELM allows you to easily manage and view all of your vCenter Servers from within the vSphere Web Client as shown in the example screenshot below.

Screen Shot 2015-02-07 at 10.34.53 AM
However, the vSphere Web Client is not the only way to start a xVC-vMotion, you can also automate it through the use of the vSphere API. In fact, there is even an "Extended" capability of xVC-vMotion that is not very well known which I have written about here which allows to live migrate a running VM across two different vCenter Servers that are NOT part of the same SSO Domain. This Extended xVC-vMotion (unofficially I am calling it ExVC-vMotion) is only available when using the vSphere API as the vSphere Web Client is unable to display vCenter Servers that are part of another SSO Domain. Below is a quick diagram to help illustrate the point in which VM1 can be seamlessly migrated between different vCenter Servers from within the same SSO Domain as well as between different vCenter Servers that are not part of the same SSO Domain.

xvc-vmotion-between-same-and-different-sso-domain-0
Note: For additional details and requirements for Cross vCenter vMotion, please have a look at this VMware KB 210695 and this blog post here for more information.

UPDATE (06/15/17) - I have added a few minor enhancements to the script to support migrating a VM given a vSphere Resource Pool which enables the ability to migrate to and from VMware's upcoming VMware Cloud on AWS (VMC). There is also an additional UppercaseUUID parameter which seems to be required for some xVC-vMotions where the vCenter Server's InstanceUUID must be provided as all upper case or the operation will fail. I have still not identified why this is needed for some migrations, but for now there is a nice flag that can be used to enable this if you are hitting this problem.

UPDATE (04/08/17) - In vSphere 6.0 Update 2, there is a known limitation which prevents a VM that has multiple VMDKs stored across different datastores to be xVC-vMotion (compute only) using the vSphere Web Client. This limitation no longer exists in vSphere 6.0 Update 3 but does require customers to upgrade. If you need to perform a compute-only xVC-vMotion where the VM has multiple VMDKs across different datastores, the vSphere APIs does not have this limitation and you do not necessary need to upgrade to be able to perform this operation. Huge thanks to Askar Kopayev who discovered this and also submitted an enhancement to my xMove-VM PowerCLI script to support this functionality.

Given the amount of interest recently and some of the feedback on my original ExVC-vMotion script which I had written about here, I figured it was time to refactor my code so that it could easily support both ExVC-vMotion as well as standard xVC-vMotion. In addition, I have also added support for migrating to and from a Distributed Virtual Switch (VDS), where as previously the example only supported Virtual Standard Switch (VSS). Lastly, the script now also supports migrating a VM that is configured with multiple vNICs.

The new script is now called xMove-VM.ps1 and is even more simpler than my original script. You will need to edit the script and update the following variables:

Variable Description
vmname Name of the VM to migrate
sourceVC The hostname or IP Address of the source vCenter Server in which the VM currently resides in
sourceVCUsername Username to the Source vCenter Server
sourceVCPassword Password to the Source vCenter Server
destVC The hostname or IP Address of the Destination vCenter Server in which to migrate the VM to
destVCUsername Username to the Destination vCenter Server
destVCpassword Password to the Destination vCenter server
datastore Name of the vSphere Datastore to migrate the VM to
cluster Name of the vSphere Cluster to migrate the VM to
resourcepool Name of the vSphere Resource Pool to migrate the VM to
vmhost Name of the ESXi host to migrate the VM to
vmnetworks Name of the vSphere Network(s). in the order in of the vNIC interfaces to migrate the VM to
switch Name of the vSphere Switch to migrate the VM to that is comma separated and ordered by vNIC
switchtype The type of vSphere Switch (vss or vds)
xvctype Whether this is a Compute-only Cross VC-vMotion (1=true or 0 = false)
UppercaseUUID There cases where the vCenter Server InstanceUUID must be all caps ($true or $false)

Here is a screenshot of running the script:

Screen Shot 2016-05-25 at 8.01.50 PM
Note: When changing the type of vSphere Switch, the following combinations will are supported by the script as well as using the vSphere Web Client: VDS to VDS, VSS to VSS and VSS to VDS. VDS to VSS is not supported using the UI or API and neither are 3rd party switches supported.

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
  • Auditing vMotion Migrations

Categories // Automation, vSphere 6.0 Tags // Cross vMotion, ExVC-vMotion, PowerCLI, RelocateVM_Task, sso, vSphere 6.0, vSphere API, vsphere web client, xVC-vMotion

  • « Previous Page
  • 1
  • …
  • 34
  • 35
  • 36
  • 37
  • 38
  • …
  • 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
  • Mastodon
  • Reddit
  • RSS
  • Twitter
  • Vimeo

Recent

  • Automating the vSAN Data Migration Pre-check using vSAN API 06/04/2025
  • VCF 9.0 Hardware Considerations 05/30/2025
  • VMware Flings is now available in Free Downloads of Broadcom Support Portal (BSP) 05/19/2025
  • VMUG Connect 2025 - Minimal VMware Cloud Foundation (VCF) 5.x in a Box  05/15/2025
  • Programmatically accessing the Broadcom Compatibility Guide (BCG) 05/06/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...