StarWind is a hyperconverged (HCI) vendor with focus on Enterprise ROBO, SMB & Edge

Exploring VMWare’s VPID Technology

  • January 11, 2017
  • 8 min read
Gary is a virtualisation, storage and Windows systems administrator who also occasionally ventures into Linux and networking and cloud areas. Container user, Windows tech, Veeam Vanguard, Spiceworks moderator. A very firm believer that the best way to solve a problem is to start with a hot cup of tea.

I’ve been using VMWare’s VPID (Virtual Port ID) technology for some time now both in work and in the home lab but I was curious to see just how VMWare handled a NIC going down and then coming back up and it turned out to be a lot more powerful and smooth than I first though.

In my lab, I’ve got several HP Microservers and a mix of TP-Link and Netgear switches.
I’ve found the TP-Link switches to be perfect for a lab as they have 48 1GBit ports and 4 1GBit FC ports. They haven’t cheapened out like Netgear have with the link between the last two Ethernet and the first two FC. With Netgear, you can only use last two Ethernet OR the first two FC ports.
You cannot use all of the ports on the switch. With TP-Link, all the ports are available and I find the web GUI a little more initiative although I did experience a bug on the TP-Link where the SNMP Engine kept crashing. This was fixed in a firmware upgrade so it wasn’t a major issue.

Anyway back to VMWare and VPID!

Once I had the switches up and running, I added them all to Observium. If you’ve not come across Observium before then it’s really something you should check out. It is a nice little application that can be installed fairly easily on Linux and will poll switches and other devices for information such as bandwidth and switch port errors.

Observium also has a couple of other features where it can alert if a port goes down, this can handy when working in datacentre as it’s very easy to accidentally dislodge a cable. This is also where things like VPID and teaming in windows and bonding in Linux can save you from an outage.

On my test lab, I’ve a VM called “DCS04” which has an IP of and a MAC of 00-50-56-93-2b-c9. The MAC clearly shows that it’s a VMware VM as any MAC starting “00-50” is a VMWare VM.

On my ESXi host, I can see that this VM is being served through vmnic1 as the hypervisor only has one physical NIC allocated to the vSwitch.

Virtual Machine Port Group

Searching in Observium and I can see the connection showing up in the FDB (Forwarding database, basically the MAC address table). Observium clearly shows me all the other VM’s on that connection as well as the physical NIC itself.

FDB table

If I now drop another NIC into the vSwitch whilst continuously pinging DCS04 I see this:

Virtual Machine Port Group


A couple of ping packets take longer than others. Not a big deal and it could be down to the server being busy. The important things it that there are no packet drops.

Observium polls the switches every five minutes for changes so, one poll later and I can see this on port 13 which is where this server was:

FDB table

It’s actually moved the traffic of several machines off that NIC and onto the one I just added to the vSwitch, a search for the MAC and I can now see it on port 17 along with a few other VM’s.

FDB table

When adding additional physical NICs into a vSwitch and, as long as they are not standby adapters, VMWare will immediately migrate part of the workload to the new NIC. The same is true if a NIC is removed, unplugged or fails, VMWare will move the traffic to other surviving NICs. It does this all dynamically. The nice thing about VPID is that it’ll work across different switch hardware, other teaming protocols like LACP generally need the same switch hardware.

VPID is a very nice technology that allows for spreading the VM load across multiple NICs and for providing some level of fault tolerance for an ESXi host. Add Observium into the mix for near real time stats on how busy a network port is plus alarms should a NIC be unplugged and you’ve got quite a nice environment for seeing just how much traffic an ESXi host will use.

Similar switch agnostic technology exists in Windows via the server manager GUI:

Nic Team


Back to blog