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 192.168.30.101. 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:
[guestinfo]
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.
[guestinfo]
primary-nics=eth0
low-priority-nics=eth1,eth2,eth3
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?
P. Cruiser says
Any reason the document for deploying the tools with SCCM is restricted?
https://communities.vmware.com/docs/DOC-36242
William Lam says
No, it should be public. I've reported this to our release team, so hopefully that'll get fixed soon
M. Just says
You can find the document for SCCM intergration here
https://www.vmware.com/techpapers/2017/deploying-vmware-tools-using-sccm-user-guide.html
Mike D says
Will this be in opentools also for Linux?
William Lam says
Yes, this is also available with open-vm-tools 10.2
I've updated the article to include RN / Download
Anthony Hirsch says
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.
R.A. Teunissen says
Thanks, I was looking for this.
Btw, I like rename the nic in the linux guest OS with the vmware vNIC/assigned portgroup name?
Tommy says
Usecase: we have always at least two NICs on customers VMs, their PROD interface and MGMT interface. We are collecting IPs info reported from VMtools. It is red by Cloudforms and then send to Service-NOW. Here comes intresting part. We use CryptoAuditor system for auditing and allowing access(RDP,SSH) for our technicians to customer VMs over MGMT interface. CryptoAuditor reads IP info and allowed groups from Service-NOW and allow our technicans to connect to customer server using MGMT IP. So if the field MGMT IP is filled with wrong IP(veth or docker instead of real MGMT), our technicians are not able to log in 🙂