WilliamLam.com

  • About
    • About
    • Privacy
  • VMware Cloud Foundation
  • VKS
  • Homelab
    • Resources
    • Nested Virtualization
  • VMware Nostalgia
  • Apple

How to obtain GID and LWID from esxtop?

11.20.2010 by William Lam // 11 Comments

Last week I remember seeing a tweet from Duncan Epping regarding the use of VMware vsish to obtain the VMX Cartel ID, also known as the LWID (Leader World Id) for a virtual machine world. This VMX Cartel ID is then used to obtain the GID (Group Id) which was documented by Duncan on his esxtop page to limit the view in esxtop to a particular VM of interest:

VMWID=`vm-support -x | grep |awk '{gsub("wid=", "");print $1}'`
VMXCARTEL=`vsish -e cat /vm/$VMWID/vmxCartelID`
vsish -e cat /sched/memClients/$VMXCARTEL/SchedGroupID

As you can see from the above, Duncan utilizes the vm-support to obtain the WID (World ID) and then using vsish to query for the VMX Cartel ID (LWID). Finally, using LWID, he was able to obtain the GID (Group ID). This example only applies to ESXi, since classic ESX does not include vsish tool.

Here is an example of where to locate the values in esxtop under CPU section:

I remember during some of my skunk work adventures, there were other methods of obtaining these IDs. Due to my VCAP-DCD cramming last week, I did not get a change to further investigate. Now that I have some time, I thought share some of these other methods for obtaining the GID and LWID in both ESX and ESXi.

ESXi

Obtaining VMX Cartel ID (LWID)

vmdumper - This will list all running VMs including the path to the .vmx configuration file, the display name of your VM and the VMX Cartel ID

~ # /sbin/vmdumper -l
wid=16881 pid=-1 cfgFile="/vmfs/volumes/4cdeeb09-1ad4c18a-5ff9-003048d9586a/scofield/scofield.vmx" uuid="42 34 e6 bc f1 83 c2 db-fb fb 08 73 b7 0c 26 40" displayName="scofield" vmxCartelID=16880

ps - The VMX Cartel ID is actually both the PID and CID within process status in ESXi

~ # ps -Cc | grep "scofield" | grep -v grep | awk '{print $2}'
16880

vscsiStats - The VMX Cartel ID is also used in identifying the VMs when displaying vscsi information

~ # /sbin/vscsiStats -l | grep "scofield" | awk '{print $4}' | sed 's/,//g'
16880

esxcli - You can obtain pretty much the same information as in vmdumper using the new "vm" option in esxcli

~ # /sbin/esxcli vms vm list | grep -A3 "scofield" | grep Cartel | awk '{gsub("VMX Cartel ID:", "");print $1}'
16880

Obtaining GID

Method1 - Using vscsiStats and esxcfg-info to extract VM's GID

~ # VM_NAME=scofield;VMX_CARTEL=$(/sbin/vscsiStats -l | grep "${VM_NAME}" | awk '{print $4}' | sed 's/,//g');esxcfg-info -r -F perl > /tmp/esxcfg-info.txt;grep -B1 "vm.${VMX_CARTEL}" /tmp/esxcfg-info.txt | head -1 | awk '{print $3}' | sed 's/,//g'
4639

Method2 - Using esxcli and esxcfg-info to extract VM's GID

~ # VM_NAME=scofield;VMX_CARTEL=$(/sbin/esxcli vms vm list | grep -A3 ${VM_NAME} | grep Cartel | awk '{gsub("VMX Cartel ID:", "");print $1}');esxcfg-info -r -F perl > /tmp/esxcfg-info.txt;grep -B1 "vm.${VMX_CARTEL}" /tmp/esxcfg-info.txt | head -1 | awk '{print $3}' | sed 's/,//g'
4639

Method3 - Using esxcli and vsish to extract VM's GID

~ # VM_NAME=scofield;VMX_CARTEL=$(/sbin/esxcli vms vm list | grep -A3 ${VM_NAME} | grep Cartel | awk '{gsub("VMX Cartel ID:", "");print $1}');/sbin/vsish -e cat /sched/memClients/${VMX_CARTEL}/SchedGroupID
4639

Note: You just need to substitute VM_NAME variable with the display name of of the virtual machine you are interested in. There are actually multiple commands being executed in this one line. If your VM has spaces, make sure you put quotes around it

ESX

Obtaining VMX Cartel ID (LWID)

vmdumper - This will list all running VMs including the path to the .vmx configuration file, the display name of your VM and the VMX Cartel ID

[root@himalaya ~]# /usr/lib/vmware/bin/vmdumper -l
wid=29250 pid=-1 cfgFile="/vmfs/volumes/4a48004d-f9af7fa0-5bbf-003048d9586b/STA202G/STA202G.vmx" uuid="42 30 d1 75 c5 3e 81 2a-14 15 1f 86 bb 5b b9 e5" displayName="STA202G" vmxCartelID=29249

vscsiStats - The VMX Cartel ID is also used in identifying the VMs when displaying vscsi information

[root@himalaya ~]# /usr/lib/vmware/bin/vscsiStats -l | grep "STA202G" | awk '{print $4}' | sed 's/,//g'
29249

esxcli - You can obtain pretty much the same information as in vmdumper using the new "vm" option in esxcli

[root@himalaya ~]# /usr/sbin/esxcli vms vm list | grep -A3 STA202G | grep Cartel | awk '{gsub("VMX Cartel ID:", "");print $1}'
29249

Obtaining GID

Method1 - Using esxcli and esxcfg-info to extract VM's GID

[root@himalaya ~]# VM_NAME=STA202G ;VMX_CARTEL=$(/usr/sbin/esxcli vms vm list | grep -A3 ${VM_NAME} | grep Cartel | awk '{gsub("VMX Cartel ID:", "");print $1}');esxcfg-info -r -F perl > /tmp/esxcfg-info.txt;grep -B1 "vm.${VMX_CARTEL}" /tmp/esxcfg-info.txt | head -1 | awk '{print $3}' | sed 's/,//g'
197

Method2 - Using sched-stats to extract GID

[root@himalaya ~]# VM_NAME=STA202G;VMX_CARTEL=$(/usr/lib/vmware/bin/vscsiStats -l | grep "${VM_NAME}" | awk '{print $4}' | sed 's/,//g');/usr/bin/sched-stats -t groups | grep "vm.${VMX_CARTEL}" | awk '{print $1}'
197

Method3 - Using /proc information from sched

[root@himalaya ~]# VM_NAME=STA202G ;grep "${VM_NAME}" /proc/vmware/sched/drm-stats | awk '{print $1}'
197

As you can see, there are more than one way to obtain the same exact values and I am sure there are probably a few others. For command simplicity, I would probably recommend method #3 for ESXi and method #3 for ESX. As with anything, be careful when you using these methods as they are not really supported by VMware unless directed by their support organization.

Categories // Uncategorized Tags // esxcli, esxtop, gid, lwid, vmdumper, vscsiStats, vsish

Hidden esxcli APIs

08.28.2010 by William Lam // 3 Comments

A few months back I wrote a three part article about esxcli (part1,part2,part3) and mentioned that no APIs existed. I recently discovered while working on automating ESXi 4.1 installations that this was not the case. I noticed an interesting module called "EsxCLI" that was being loaded while watching the boot logs and that the format of the string match those of the managed object reference names found in vSphere API.

(vim.EsxCLI.corestorage.claiming) ha-cli-handler-corestorage-claiming
(vim.EsxCLI.corestorage.claimrule) ha-cli-handler-corestorage-claimrule
(vim.EsxCLI.corestorage.device) ha-cli-handler-corestorage-device
(vim.EsxCLI.corestorage.plugin) ha-cli-handler-corestorage-plugin

(vim.EsxCLI.network.connection) ha-cli-handler-network-connection
(vim.EsxCLI.network.neighbor) ha-cli-handler-network-neighbor

(vim.EsxCLI.nmp.boot) ha-cli-handler-nmp-boot
(vim.EsxCLI.nmp.device) ha-cli-handler-nmp-device
(vim.EsxCLI.nmp.fixed) ha-cli-handler-nmp-fixed
(vim.EsxCLI.nmp.path) ha-cli-handler-nmp-path
(vim.EsxCLI.nmp.psp) ha-cli-handler-nmp-psp
(vim.EsxCLI.nmp.roundrobin) ha-cli-handler-nmp-roundrobin
(vim.EsxCLI.nmp.satp) ha-cli-handler-nmp-satp

(vim.EsxCLI.swiscsi.nic) ha-cli-handler-swiscsi-nic
(vim.EsxCLI.swiscsi.session) ha-cli-handler-swiscsi-session
(vim.EsxCLI.swiscsi.vmknic) ha-cli-handler-swiscsi-vmknic
(vim.EsxCLI.swiscsi.vmnic) ha-cli-handler-swiscsi-vmnic

(vim.EsxCLI.vaai.device) ha-cli-handler-vaai-device

(vim.EsxCLI.vms.vm) ha-cli-handler-vms-vm

As you can see, all six current namespaces are implemented within the vSphere API with a new managed object called "EsxCLI" just like the esxcli utility:

These APIs of course are hidden and have not been exposed in any of the vSphere SDKs (vSphere SDK for Perl, PowerCLI, VI Java, etc), however, you can access them via the vSphere MOB. As far as I can tell, this is new with vSphere 4.1 and was not available with vSphere 4.0 (unconfirmed).

To access these API methods, you just need to open up a browser and use either an ESX or ESXi host and generate the following url (https://[esx_or_esxi_server]/mob/?moid=ha-cli-handler-vms-vm) and appending one of the above managed object path that begin with ha-

Here is an example of using esxcli's VM namespace:

We can invoke one of the two supported methods for this namespace. We'll query for any available running VMs by just clicking on the method which will open up a new window. You will now click on the "Invoke Method" as it does not require any additional paramters:

You can see this output matches that of esxcli:

I heard that esxcli API would eventually be exposed but may not be available for public consumption, it looks this is not entirely true. VMware, why are you holding out on us? Make your APIs public!

Categories // Uncategorized Tags // esxcli, vSphere 4.1

How to kill a stuck VM on ESX(i) 4.1 using esxcli

08.14.2010 by William Lam // 1 Comment

With so many new features in vSphere 4.1, you might have not noticed the new additions to the esxcli utility. One new feature is the ability to remotely kill a stuck or hung virtual machine running on ESX or ESXi. Prior to vSphere 4.1, the process of killing a stuck VM meant you had to use a variety of methods and tools that included vmware-cmd, vm-support, vmkload_app and ps/kill and required the use of either Service Console on ESX or Tech Support Mode for ESXi. Depending on how "stuck" your VM was, you would start from the most gentle method to killing your VM with prejudice (kill -9 [pid]).

A new namespace called "vms" has now been added and there are two available operations: list running VMs on a host or killing a specific VM. To kill a VM, you will need to specify the kill type and VM's world id.

Here is an example of listing all running VMs on an ESXi host:

When a VM gets into a stuck state in which you have no other option than to forcefully stop the VM, you will have three types of options to kill a VM: soft, hard and force. Per the help command, you should always perform the kill operations in the following order:

soft - Will give the VMX process a chance to shutdown cleanly (like kill or kill -SIGTERM)
hard - Will shutdown the process immediately (like kill -9 or kill -SIGKILL)
force - Should be used as a last resort attempt to kill the VM

The final resort, is to reboot the host if none of the above work.

Here is an example of various kill types:

Here is an example of killing a VM using the "soft" method, you should see the value of "true" if the operation was successful.

This was one feature users have been asking for with regards to managing VMs on ESXi, where the Service Console was no longer available. You do not need to login to Tech Support Mode to forcefully kill a VM and from what I have been told, if the above does not work, it will not work in Tech Support Mode either. I am hoping a public API for esxcli operations will be exposed which can be leverage by the various vSphere SDK's (e.g. vSphere SDK for Perl, PowerCLI, VI Java, etc.)

Categories // Uncategorized Tags // esxcli, vSphere 4.1

  • « Previous Page
  • 1
  • …
  • 10
  • 11
  • 12
  • 13
  • 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

  • Programmatically accessing the Broadcom Compatibility Guide (BCG) 05/06/2025
  • Quick Tip - Validating Broadcom Download Token  05/01/2025
  • Supported chipsets for the USB Network Native Driver for ESXi Fling 04/23/2025
  • vCenter Identity Federation with Authelia 04/16/2025
  • vCenter Server Identity Federation with Kanidm 04/10/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