Mapping VM vnic to ESXi vmnics


Esxtop is the standard way to determine what vmnic is supporting a virtual machines vnic on an ESXi hypervisor. This involves pulling up a command line interface on an ESXi server, running command esxtop, pushing the "n" key and reading the list of VMs to identify which switchport is mapped to which physical nic. I will show the screenshots to demonstrate it, however there is an alternative method. First, lets see the method I've described above. 

In this blog, were working with an ESXi server named esx-01a.corp.local.


We SSH to the server and run command "net-stats -l". Make note of the Port ID.


Next, run command "esxtop". The default view of esxtop shows cpu and process metrics. For our use case, we want to see network statistics. Push the "n" key, then locate the two Port IDs noted previously.



Alternatively, you can use the following CLI commands to find the VMs world ID (something like a process ID) and map that to a vmnic.

First we use command "esxcli vm process list" to find the VMs world ID.




 Then we feed the world ID into the command "esxcli network vm port list -w [World ID]". Notice that the output of this command also lists the Port ID of the VM and mac address of the VM in the event the VM has multiple vnics. This will allow you to differentiate the two vnics.



For some added fun, consider trying out my python script which connects to an ESXi hypervisor, lists the VMs and maps each vnic to its vmnic:
https://github.com/allend2092/map_vnic_to_vmnic_esxi/blob/main/map_vnic_to_pnic.py

The script outputs the data to a json file. Here is an example:
https://github.com/allend2092/map_vnic_to_vmnic_esxi/blob/main/output_example.json









Comments

Post a Comment

Popular posts from this blog

VXLAN versus GENEVE (NSX-V vs. NSX-T)

Image
  August 14th, 2021 With the ramp-up of NSX-T overlay networks and transition away from NSX-V overlay networks, it's a good time to look at one of the fundamental differences between them. NSX-V uses VXLAN as its encapsulation protocol while NSX-T uses the more recent GENEVE encapsulation protocol. Each require the physical networking devices have their MTU adjusted to 1600 bytes or greater. We'll take a detailed look at why that is. First, the basics: VXLAN is: short for Virtual eXtensible Local Area Network Is defined in rfc 7348 - https://datatracker.ietf.org/doc/html/rfc7348 Uses UDP port 4789 8 byte header GENEVE is: short for Generic Network Virtualization Encapsulation Is defined in rfc 8926 -  https://datatracker.ietf.org/doc/html/rfc8926 Uses UDP port 6081 16 byte header From the prospective of the physical network, an overlay network is essentially an application. NSX-T is an application using well known UDP port 6081. Switching perspectives to the overlay's
Read more

"Twice NAT" with NSX-T T0 Gateway

Image
  Network address translation, or more commonly NAT, is most often used to do source NAT or destination NAT. In rare instances, SNAT or DNAT isn't enough to get ip packets to their destination. Enter twice nat. While twice NAT isn't a function I've needed often, it was a function drilled into me while studying for various Cisco exams. I used to watch Christian Matei explain it over at INE and it really helped me to understand what twice NAT is and how to configure it on Cisco devices. Previous to my time working with NSX-T, I'd only utilized twice NAT once. A few years back, a customer wanted to build and IPsec tunnel from the organization HQ to a branch office. The private ip space used by HQ and the branch used overlapping ip space. We used twice NAT to NAT the source and destination ip address in a single NAT rule ( similar to this guy ) before shoving it all into an IPsec tunnel. Previous to working with NSX, circumstances requiring twice NAT were uncommon.  While w
Read more

Packet Capture Network Traffic Inside ESXi Hypervisor

Image
The three components of computer infrastructure are considered compute, storage, and networking. When applications don't work properly, its often the case that networking is the first component to receive blame for failed application performance. In the case of virtualized workloads (i.e. applications running on virtual machines), we are fortunate to have a powerful troubleshooting tool which allows us to packet capture network traffic in an ESXi hypervisor. For this blog, I'm going to use an Hands On Lab (HOL) from the VMware website to demonstrate the process of doing a quick live packet capture. The output of the packet capture will be sent to the shell of the hypervisor. There are ways to sent the network traffic to a file so it can be extracted and analyzed by a packet analyzer tool, but that will be for another post. First, lets start with heading over to the HOL website:  https://labs.hol.vmware.com/ For this lab, I'm going to type NSX in the search bar to find
Read more