As you may know, ESXi Management interface (aka vmk0) is created during installation. By default that interface will inherit MAC address of one of the physical NIC cards. Now, this is not a problem at all in most cases, but sometimes it can create problems.
For example imagine a situation where you do an installation with a one 1G physical NIC, and then you want to do an upgrade. You take out 1G NIC and insert 10G one. After that you reuse 1G NIC in another server. This can lead to situation with duplicate MAC addresses on the network.
Update: VMware KB 55626 – MAC Flapping observed in an NSX Environment covers a specific case when this can affect you. According to the KB there is no resolution for now, but the steps bellow can help you solve it.
Removing and re-creating management interface will create it with a VMware MAC address as any other VMkernel interface. So this can resolve duplicate issue.
And honestly, it doesn’t matter much what is the reason for you doing this, important is to know how-to.
If you are using Standard Switches, the procedure is pretty straight forward so i will not cover it. It becomes a bit complex in case your Management interface was migrated to Distributed Virtual Switch. And this is exactly the case I will cover here.
All these steps will need to be performed using direct console, as we will be deleting the interface. It is also a good idea to put the host into Maintenance Mode.
Collect configuration details
First of all you need to capture current IP configuration of your management interface. I mean IP, Netmask and Gateway. We will also need name of the dvswitch which has the vmk0 interface. All this info will be needed.
Find Port ID
Second, you will need to find a port number on dvswitch which is used by vmk0. To list Switch inso you can use esxcfg-vswitch -l and then look for vmk0. If you are in same situation as I am the output of that command can be very long, so you can use grep and awk to filter out only the value we need.
esxcfg-vswitch -l |grep vmk0 |awk '{print $1}'
Remove vmk0
As third step, we need to remove current vmk0, thats easy, just run the command:
esxcli network ip interface remove --interface-name=vmk0
We can check if it was removed my running esxcfg-vmknic -l or we can check if the port was freed by running esxcfg-vswitch -l and looking for the port number we acquired in second step.
Re-Create vmk0
Now once we have old vmk0 removed, we can run following command to recreate it:
esxcli network ip interface add --interface-name=vmk0 --dvs-name=DVSWITCHNAME --dvport-id=PORT_ID_FROM_STEP_TWO
Of course you will need to replace DVSWITCHNAME with your Distributed Switch name and PORT_ID_FROM_STEP_TWO with the Port ID we acquired in step 2.
Again, we can check if port was created using esxcfg-vmknic -l or esxcfg-vswitch -l.
Configure IP settings
In step number 5 we need to assign IP configuration to the new vmk0 interface. Use the following command to do it. Replace IP and NETMASK with info captured in step 1.
esxcli network ip interface ipv4 set --interface-name=vmk0 --ipv4=IP --netmask=NETMASK --type=static
Set default Gateway
We also need to set the default GW back to its place, as it was removed once we removed vmk0.
esxcfg-route -a default IP_OF_GW
Mark vmk0 for Management traffic
It may happen that vmk0 will not be marked for Management traffic after recreation. You can use the following command to mark interface for management in CLI.
esxcli network ip interface tag add -i vmk0 -t Management
That’s it for this small How-To. Hope it helps.
Latest posts by Aram Avetisyan (see all)
- Make Youtube Videos About Technology? Why not… The Cross-Cloud Guy - October 7, 2021
- Automating (NSX-T) REST API using Ansible URI module - December 29, 2020
- Quick Reference: Create Security Policy with Firewall Rules using NSX-T Policy API - May 4, 2020
Hi Aram,
Thanks for this article. In our environment when I run esxcfg-vmknic -l I always see the management network (vmk0) having the mac address of our UCS system while other vmknics have vmware mac addresses. As you state this seems normal. However it seems after we apply patches to our ESXi hosts and I vmotion our vCenter server back to the original host the vCenter appliance always gets messed up. It seems the vmotion fails at about 70-80% and then all of the hosts in our environment disconnect. I then have rerun the esxcfg-vmknic -d -p and then esxcfg -a -i cmds (as shown in KB 1031111) and then disconnect and reconnect all of the hosts. This seems very weird. Have you ever heard of this behavior before?
Also once I run those esxcfg-vmknic cmds and all of the vmknics get VMware MACs addresses is there a way to make this permanent?
Thank You.
Matt
Hi Matt,
Sorry for a very late reply. Somehow i missed your comment. To me honest the behaviour you describe is actually really weird. I haven’t had chance to work with it unfortunately. Can it be related tot he was UCS handles networking? AFAIK in UCS you can create your own ‘vNics’ which are visible to ESXi as Physical nics.. Have you tried to raise support requests to Cisco or to VMware? I would be curious to know what the outcome was.
This really saved my butt. Thank you so much for such a clear guide.
🙂 Glad to hear it helped!
Extremely useful and to the point! 🙂
This might help a lot during NSX-T host prep where you are forced to migrate vmk0 to N-VDS along with vmnic0 just cause they share the MAC. If MAC of vmk0 can be changed then one need not worry about migrating vmk0 unnecessary.
True, i actually had to do it on one NSX-T Deployment recently. Although have to admit, i rarely see NSX-T deployment on a cluster with dvSwitch, most of the time you get brand new hosts with standard, and you move standard to n-vds. and recreating vmk0 on standard switch is so much easier.
I see this effect anytime, when a vmk0 at a nested-ESXi-Host has to be migrated from (standard-)vswitch0 to a distributed-switch, for example using the cloud-builder@vcf4 – in conjunction with dynamic mac-learning at the base-switch connecting all esxi-hosts togerher and disabled promiscous mode.
Any idea how to do this using powershell/powercli? deleting vmk0 will drop your powercli-connection… so …a) creating a (dummy-)vmk1 b) connect to vmk1-ip c) delete and recreate vmk0 d) delete vmk1 – not very elegant…
right now, i’m using ssh and apply all esxi-commands at one line using “;” as seperator between those multiple esxcli-commands…
well, i am not really a PowerCLI guy, but AFAIK, so cant tell how exactly it can be done. As far as I remember PowerShell should have Invoke-SSH cmdlet, so, may be, you can pack all you do over SSH into a powershell script? Let me know if you figure it out at some point, i am also interested.
how about if vmk0 is tagged with vlan ID. How are you expected to assign the vlan id on VDS
VLAN ID is a portgroup related parameter and not specific port parameter, so there is no way to assign VLAN ID to vmk0 itself or tot he port it is connected to, rather it needs to be assigned on PortgGroup which vmk0 is connected to. i don’t remember if there is a way to create distributed portgroup using esxcli, i know you can do it for standard switch though.
I was hunting this MAC flapping issue the whole afternoon on a new server. A few pings lost every 20 seconds or so. When I created a new vmkernel adapter – no pings lost using the same vSwitch. The issue was as suspected a wrong MAC from another NIC in the server. So I recreated the vmk0 using the correct MAC and now no packet loss. Thanks !
Very happy to hear that this ancient article is still useful )))