WilliamLam.com

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

vSphere Tagging Feature Not So Invisible

06.08.2011 by William Lam // 9 Comments

This evening I was reading a new blog post Tagging: An Invisible Feature in vSphere by Steve Jin in which he describes a hidden vSphere feature for tagging particular managed entities in your vSphere environment. The main consumer of this hidden feature is primarily VMware and it provides a level of meta data tagging to denote the importance of an entity. These tags are used in workflows in various vSphere products such as vCenter Server, vCenter Update Manager and View to just name a few.

Here is a screenshot of a VM entity using the vSphere MOB and as you can see from the tags, VMware can identify that this particular VM is running both vCenter Server and vCenter Update Manager.

If you have a VM that is a View Replica/Linked Clone, you may see these tags associated with the VM:

SYSTEM/COM.VMWARE.SIM.SVIMANAGEDOBJECT
SYSTEM/COM.VMWARE.VIM.SVIMANAGEDOBJECT

This feature can be really useful to allow users to tag particular objects in their environment of importance and easily correlate/integrate with a provisioning system and/or CMDB without having to resort to a separate database to store the meta data. You might say that custom fields exists today that can provide the same level of functionality, but they are actually pretty limited in scope. It only allows you to create custom attributes at a global vCenter level, host and virtual machine but not all managed objects such as Datastore, Networks, Resource Pool, etc.

So what if you wanted to create your own custom tags? Since these are hidden methods from VMware and they are not exposed through the public vSphere API, how might we access it? I spent a few minutes of digging and I was able to identify the two methods that pertained to tag management in the vSphere API:

addTag - Adds a tag to a managed entity
removeTag - Removes a tag to a managed entity

You can access both of these methods using the vSphere MOB as none of the official vSphere SDKs have these methods implemented. These methods are only supported when connecting to vCenter Server and are not exposed at an ESX(i) level.

In this example, I will create a custom tag at the Datacenter level called "WWW.VIRTUALLYGHETTO.COM"

Here is the path to a Datacenter object using the vSphere MOB:

If we scroll down on the page, you will notice a property called "tag" and as you can see in the screenshot below, no tags have been defined:

I will now craft the URL to the "addTag" method using the Datacenter as a point of reference:

https://reflex.primp-industries.com/mob/?moid=datacenter-1246&method=addTag

As you can see the method accepts an array of tags which can be defined within the section. All tags MUST begin with "SYSTEM/" and then a unique string following, in our example I used "SYSTEM/WWW.VIRTUALLYGHETTO.COM". Once you have created your tag, you will then click on the "Invoke Method" to add the tag. Since this method does not return anything, the return result is void.

Now if we go back to the Datacenter page and refresh the page, you should see the new tag that was just created:

To delete a tag, you will generate the same URL but replace "add" with "remove":

https://reflex.primp-industries.com/mob/?moid=datacenter-1246&method=removeTag

You will again fill in the tags to be removed and then click on "Invoke Method":

As you can see, you now have the power to create your own tags on various managed entities in your vSphere environment. If you want to automate this through a script or command line, you can create simple HTTP POST operations to the vSphere MOB or create the appropriate interface methods to the SDK bindings to support these hidden methods. I'll leave the latter as an exercise for the readers.

Categories // Uncategorized Tags // api, tag, vSphere

How to query for MACs on internal vSwitch on ESXi

05.28.2011 by William Lam // 10 Comments

There was an interesting question this week on the VMTN community forums about querying a vSwitch on an ESX(i) host. The user was trying to locate a particular virtual machine's MAC Address due to an IP conflict that was identified. The internal VMware vSwitch is pretty much closed off as a blackbox. The vSwitch is not exposed like a traditional physical switch in which you can run commands against such as "show mac-address-table" to display the MAC addresses found on the switch.

However, you can still perform a lookup of all the MAC Addresses found on a particular ESX(i)/vCenter host by using the vSphere APIs. You can search for all virtual machines and dump out their associated MAC Addresses and correlate that back to a particular vSwitch. You can easily do this through a script such as using the vSphere SDK for Perl script: getvSwitchMacTable.pl which supports both stand vSwitch and distributed vSwitch or if you prefer a GUI, you can use the popular RVTools. I am sure there is most likely a PowerCLI solution to solving this problem as well.

The solution described above is the proper and most flexible way of solving this problem, but what if you really wanted to query the internal vSwitch and extract out the MAC Addresses that way? Well the answer is, you can so using vsish on ESXi (vsish is not available on ESX unless you have the VMware debugging RPM package installed).

Here are some of things you can view for a given vSwitch using vsish:

~ # vsish -e ls /net/portsets/vSwitch0
ports/
overlays/
uplinks/
type
mtu
unlink
link
destroy
properties
stats

The "ports" section is what we are interested in:

~ # vsish -e ls /net/portsets/vSwitch0/ports
16777217/
16777218/
16777219/
16777220/
16777358/
16777359/

When looking at a particular port, it provides quite a bit of information on what is connected and various metrics/statistics:

~ # vsish -e ls /net/portsets/vSwitch0/ports/16777220/
respool/
e1000/
vmxnet3/
pktSizes/
clusterSizes/
worlds/
coalesceDetailed/
ip
schedTeamUplink
teamUplink
blocked
injectIGMP
txCompCoalesce
txCoalesce
rxCoalesce
controlChain
notifyStats
inputStats
outputStats
vmxnet2clientStats
clientStats
gateway
setPassthru
status
stats

As you can see it is pretty tedious to go through each of the ports and it does not easily allow you to figure out what is exactly connected to the port until you view the "status" property.

I decided to write a tiny script that would allow a user to dump out all the MAC Addresses from the vSwitch(s) found on an ESX(i) host. Not only does it provide this mapping but also what is specifically using a given port whether it is mapped to internal interface or a particular virtual machine.

You can download the script vswitchInfo.sh which runs directly on ESXi's TSM (Tech Support Mode). The script can be called with the "-l" option to provide a high level dump of all MAC Addresses. Once you have identified the particular vSwitch and port, then you can get further details by specifying "-v" for vSwitch name and "-p" for the port number as displayed from the previous execution.

Here is an example output of just listing all MAC Addresses from all vSwitch(s) in an ESXi host:

Here is an example of getting more details on a particular port on a vSwitch:

Here you can see the clientName which is either a VM or interface using the port. You will also notice there is a mapping to set of pNICS that are attached to the vSwitch and various other details that I will let you explore.

You might have noticed the vSwitch port-ids looks kind of familiar? If you did, they actually are, as they part of the "networking" section in esxtop/resxtop output.

Unfortunately with esxtop/resxtop, it does not display the associated MAC Addresses, but now you have a way to easily query for details on the internal ports of a vSwitch.

Note: The second solution falls under the "not supported" category as you might have guessed.

Categories // Uncategorized Tags // ESXi 4.1, vsish, vswitch

ESXi Migration Worksheet Script

05.26.2011 by William Lam // 7 Comments

Over the weekend Duncan Epping released a new whitepaper called VMware ESXi 4.1 Operations Guide which documents some of the operational tasks for managing/configuring an ESXi environment. Not only is this a really cool document, but I also found that I was referenced in the whitepaper. This was really neat as it is probably my first reference ever in a whitepaper 🙂

While looking through the other links, I noticed there was another whitepaper written by Duncan's colleague, Kyle and it referenced a host configuration worksheet. When I opened up the document, it was basically a plain PDF form requiring users to manually input some of the important configurations of an ESX host prior to upgrading to ESXi. I thought this would be fine if you only had a few hosts to upgrade, but what if you had several dozens or hundreds of hosts? Manually editing the non-editable PDF document meant you had to use a PDF tool or worse printing it out and writing in the information by hand.

I thought, why not automate it? I decided create a very simple vSphere SDK for Perl script called generateHostConfigurationWorksheet.pl that would allow a user to connect to either a standalone ESX host or to a vCenter server. The script also allows you to specify a list of ESX hosts to extract the information when connecting to vCenter, else by default it will collect information for all your ESX hosts. You also have the option of selecting either an html or csv output.

To run this script, you will need a system that has the vCLI installed or you can use VMware vMA. You will also need to download the script from here. Make sure you set the script to be executable

The script accepts two paraemters:
--output [html|csv] (required)

--hostlist [file-containing-esx-hosts] (optional)

Here is an example of connecting directly to an ESX host:

[vi-admin@tancredi ~]$ ./generateHostConfigurationWorksheet.pl --server vesx41-1.primp-industries.com --username root --output html
Enter password:
Processing vesx41-1.primp-industries.com
Generating vesx41-1.primp-industries.com.html ...

Here is an example of connecting to vCenter and specifying a list of ESX hosts to collect information on:

[vi-admin@tancredi ~]$ ./generateHostConfigurationWorksheet.pl --server reflex.primp-industries.com --username primp --output csv --hostlist hostlist
Enter password:
Processing vesx41-1.primp-industries.com
Generating vesx41-1.primp-industries.com.csv ...

Note: If you like to select the ESX hosts you want to report on, just create a file that has the displayname of your ESX host seperated by a newline

Here is sample report that you can view

You will notice that syslog section is left blank, this is done intentionally as with ESX, syslog configuration is not exposed through the vSphere API like ESXi. This will be something you will need to fill in manually.

I think this worksheet will be useful, but if you are interested in a more extensive report prior to upgrading, I would highly recommend you check out the popular vSphere Health Check script and here is what one of those reports can look like.

Categories // Uncategorized Tags // ESXi 4.1, vsphere sdk for perl

  • « Previous Page
  • 1
  • …
  • 525
  • 526
  • 527
  • 528
  • 529
  • …
  • 561
  • 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