VMware Tools 10.2.0 just GA'ed (release notes / download and open-vm-tools release notes / open-vm-tools download) and this release includes a number of new features like an offline bundle for VMware Tools VIB for ESXi and support for deploying VMware Tools using Microsoft System Center Configuration Manager (SCCM) to just name a few. There are also two additional new capabilities that I wanted to share as I think customers can benefit from and take advantage of immediately around how Virtual Machine vNICs are displayed. One of the challenges with having the broadest Guest Operating System (GOS) support in vSphere is dealing with some of the different behaviors of each GOS. One such example are the various ways in how both physical and logical networks interfaces are enumerated by an OS.

Take the example below, I have a PhotonOS VM which has eth0 as the primary interface and it is configured with an IP Address of However, as you can see from the screenshot below I am actually getting back a different address and interface. In addition to this, we also see other logical interfaces showing up in the IP Address list such as Docker interfaces as well as virtual and other pseudo interfaces that may or may not be useful to VI Admins.

Historically, there was not a way to control what would show up in the network interface list which is then propagated from VMware Tools up to both the vSphere API as well as vSphere UI. With this new release of VMware Tools, which can be applied asynchronously to a given vSphere release, customers now have the ability to filter on a per-VM basis on what interfaces actually show up as well as a relative priority for interfaces that customers care more about.

vNIC Exclusion

The first feature is ability to exclude physical/logical interfaces from showing up when retrieving a list of network interfaces using the vSphere API/UI.

Here is the output of all my network interfaces from within my PhotonOS VM and we can see there are standard eth* interfaces, but there is also several other logical interfaces such as docker* & veth*.

Customers can update the tools.conf configuration file located within a GOS that has VMware Tools installed and append the following:

exclude-nics=[INTERFACE NAME]

docker*, veth* and vEthernet* (for Window GOS) are excluded by default. If you wish to override the system default and display these interfaces, simply set the value to an empty string. You can add other interface names if you want to exclude other types.

Note: You can refer to KB 1007873 for identifying the location of tools.conf as it depends on the type of GOS you are running. If tools.conf does not exist, simply create the configuration file. No restart of VMware Tools is required as the daemon will automatically look for updates every 5 seconds.

vNIC Priority Ordering

The second feature is the ability to prioritize more important physical/logical interfaces towards the top of the list and also specifying a lower priority for other physical/logical interfaces that you may not care about.

You can append the following into your tools.conf file and the example below prioritizes eth0 as a primary NIC and sets eth1-3 as having lower priority which ensure they show up towards the bottom of the address list.


After applying the above configuration, if we now take a look at our vSphere API/UI, we can see that not only do we have our eth0 interface listed on top but we also have excluded other interfaces (docker* and veth*) which we did not care about.

One important thing to note is that both primary-nics and low-priority-nics is not an ordered list, but rather an un-ordered list that VMware Tools will try to prioritize. Again, due to OS differences, it is currently not possible to define an ordered list. I know this is something that a few customers have asked about before and I am curious if other customers would find this useful and what use cases this might help them solve?

6 thoughts on “VMware Tools 10.2.0 enables Virtual Machine vNIC exclusion and priority re-ordering

  1. Thanks for the notification of this, this will help greatly with Automation deployments, one thing we found was that with Orchestration tools like vRA, it picks the primary NIC as it’s management address. We’ve seen some docker instances that didn’t return the correct management address which then caused management issues.

Thanks for the comment!