Recently I did a “few” upgrades to the home lab. Besides an upgrade to enhance shared storage for vSphere (my old NAS was at 502 days uptime), I took the opportunity to enable jumbo packets on my Dell PowerConnect 5324 and the new fire-and-forget Thecus N7700PRO NAS. As the basis for new lab infrastructure to test VMware, Hyper-V and Xen, it’s a good improvement.
Since the first use was to test some of the new features of vSphere / vCenter 4.1, I also took the opportunity to change over to ESXi from ESX. According to VMware, 4.1 is the last release of ESX, so time to get cracking with ESXi, vMA, and the differences in managing the hosts.
I wanted to take advantage of jumbo frames on my ESXi systems. However, I didn’t decide this until I’d already installed the hosts (and didn’t see an advanced option to set the management interface MTU).
The Problem
I couldn’t provision my NAS storage into a different VLAN / physical network, which would be best practices for storage for the ESXi hosts. And I didn’t realize that with ESXi there is no way to set tell the hypervisor which port group / vmk to use for NFS access. It’s based on the configured network of the NAS device or based on the lowest numbered vmk of the machine. And since vmk0, Management Network, is created by default with an MTU of 1500 bytes, getting that to 9000 bytes is a problem.
The Solution
So what we’re going to do is use two vmk’s to set each to an MTU of 9000 while in maintenance mode. We’ll also change the port group names to reflect the one that deals with vMotion.
Prerequisites
So we have a cluster of hosts with multiple vmnics, but with managment, vMotion and storage all in the same network. The host we are going to change is in the following environment:
- Switch and NFS storage both configured for jumbo frames and an MTU of 9000 bytes
- vMA4.0.0 (or 4.1 — I’m using 4.0 for ghettovcbg2 compatibility) and vCenter 4.1 on installed dedicated systems (or one not affected by the host we are converting)
- ESXi 4.1 configured with default MTU (1500 bytes) managed by vCenter
- VLAN is the management and storage network, VMware hosts are trunked to the the switch
- Ability to migrate guests to other cluster members
- Full permissions to the vSphere
- Working knowledge of making changes to networking and storage
The Process
Prep the ESXi Host
Our host, esx03.peanuts.local has two IP addresses, 172.16.200.90 assigned to vmk0 and 172.16.200.91 assigned to vmk1. Do the following to get the host ready:
- Migrate all running VM’s to other hosts
- Migrate powered down VM’s to another host
- Place the host into maintenance mode
- Optional – You may wish to disable HA. I found that the various connectivity changes forced HA scans that caused alerts to rise. No issues, but beware.
At this point we can do almost anything we wish to the host without affecting the rest of the environment.
Remove vmk1
At the start, vSwitch0 looks like this:
Edit the properties of the switch and remove the port group VMKernel Primary. At this point, there will be a single vmkernel, vmk0, that we’ll use to connect via the vMA.
Connect to the host via vMA
Login as the vi-admin and add the host via the IP address of vmk0, and connect. You will need the root account password for the ESXi box.
[vi-admin@vma ~]$ sudo vifp addserver 172.16.200.90 root@esx03.peanuts.local's password: [vi-admin@vma ~]$ vifpinit 172.16.200.90
Convert vSwitch0 to Support Jumbo Frames
After connecting, modify the switch and verify the settings. Note, this may cause a connectivity outage. For one host, it took 30-40 seconds to complete the command.
[vi-admin@vma ~][172.16.200.90]$ esxcfg-vswitch -m 9000 vSwitch0 [vi-admin@vma ~][172.16.200.90]$ esxcfg-vswitch -l Switch Name Num Ports Used Ports Configured Ports MTU Uplinks vSwitch0 128 5 128 9000 vmnic2,vmnic1,vmnic0 PortGroup Name VLAN ID Used Ports Uplinks ISP - Comcast 502 0 vmnic2,vmnic1,vmnic0 Development LAN 30 0 vmnic2,vmnic1,vmnic0 VM Network 10 0 vmnic2,vmnic1,vmnic0 Management Network 10 1 vmnic0,vmnic1,vmnic2
Look to ensure this the vSwitch shows 9000 under MTU.
Create the New vmk1
Create a new port group and assign it to the proper VLAN. I used a name that would be more specific to the purpose once we’re done (vMotion).
[vi-admin@vma ~][172.16.200.90]$ esxcfg-vmknic -a -i 172.16.200.91 -n 255.255.255.0 -m 9000 "vMotion" Added the VMkernel NIC successfully [vi-admin@vma ~][172.16.200.90]$ esxcfg-vmknic -l Interface Port Group/DVPort IP Family IP Address Netmask MTU Type vmk0 Management Network IPv4 172.16.200.90 255.255.255.0 1500 STATIC vmk0 Management Network IPv6 fe80::21b:21ff:fe0f:82b 64 1500 STATIC vmk1 vMotion IPv4 172.16.200.91 255.255.255.0 9000 STATIC vmk1 vMotion IPv6 fe80::250:56ff:fe77:3517 64 9000 STATIC
Verify that vmk1 has 9000 for the MTU (I removed the MAC address field so it would show here). Note that vmk0, how we’re connected and where NFS traffic transits, is still at 1500 bytes. Not for long!
Remove vmk0
Prior to removing vmk0, use the GUI to enabled Management traffic on the new vmk1 (vMotion), then select OK:
At the vSwitch0 properties page, select and Remove the Management Network port group (vmk0):
Note: when you hit Remove and confirm, connectivity to the host will be lost until the next step. What this does is starts the process of removing the vmkernel. However, since removal of that breaks connectivity, the actual removal of the port group doesn’t take place. At least it didn’t for me.
Create New vmk0
From the vMA, forcibly remove the host by IP address (vmk0′s), then add the host via the vmk1 IP address. Verify that the vSwitch has the port group Management Network still there and assigned to VLAN 10:
[vi-admin@vma ~][172.16.200.90]$ sudo vifp removeserver 172.16.200.90 --force root@172.16.200.90's password: [vi-admin@vma ~][172.16.200.90]$ sudo vifp addserver 172.16.200.91 root@esx03-vmk.peanuts.local's password: [vi-admin@vma ~][172.16.200.90]$ vifpinit 172.16.200.91 [vi-admin@vma ~][172.16.200.91]$ esxcfg-vswitch -l Switch Name Num Ports Used Ports Configured Ports MTU Uplinks vSwitch0 128 5 128 9000 vmnic2,vmnic1,vmnic0 PortGroup Name VLAN ID Used Ports Uplinks VM Network 10 0 vmnic2,vmnic1,vmnic0 ISP - Comcast 502 0 vmnic2,vmnic1,vmnic0 Development LAN 30 0 vmnic2,vmnic1,vmnic0 vMotion 10 1 vmnic2,vmnic1,vmnic0 Management Network 10 0 vmnic0,vmnic1,vmnic2
If the port gorup isn’t there, use the steps above to create the port group and assign it to the VLAN. Now create the new vmk0 with jumbo frames and verify both vmk’s are correctly made:
[vi-admin@vma ~][172.16.200.91]$ esxcfg-vmknic -a -i 172.16.200.90 -n 255.255.255.0 -m 9000 "Management Network" Added the VMkernel NIC successfully [vi-admin@vma ~][172.16.200.91]$ esxcfg-vmknic -l Interface Port Group/DVPort IP Family IP Address Netmask MAC Address MTU Type vmk1 vMotion IPv4 172.16.200.91 255.255.255.0 00:50:56:77:35:17 9000 STATIC vmk1 vMotion IPv6 fe80::250:56ff:fe77:3517 64 00:50:56:77:35:17 9000 STATIC vmk0 Management Network IPv4 172.16.200.90 255.255.255.0 00:50:56:71:f8:b6 9000 STATIC vmk0 Management Network IPv6 fe80::250:56ff:fe71:f8b6 64 00:50:56:71:f8:b6 9000 STATIC
You can see that the MTU is correct for both vmk’s (scroll over, I left the MAC address in this time). At this point, vCenter will see the host.
Final Restart
One last reboot of the host will ensure everything is in proper order. I do this from vCenter once the host is reachable:
After the host comes back up in vCenter, we’ll clean up the networking config and storage.
Reassign Services to Proper vmk’s
Go into the vSwitch0 properties and set the port properties for each vmkernel:
Management Network - vmk0 – Management traffic - managed via vCenter / vMA, and as lowest vmk, used by NFS for storage on the same subnet.
vMotion - vmk1 – vMotion and FT (fault tolerance logging). Deselect Management traffic.
When you select OK, this will finalize the port group settings.
Clean Up
At this point, all NFS traffic (actually any traffic) can now use jumbo frames. I’d go over to Storage and refresh to make sure the store populates as expected. Finally, we’ll clear out the host entry in the vMA and add using the FQDN (a topic for another posting!):
[vi-admin@vma ~][172.16.200.91]$ sudo vifp removeserver 172.16.200.91 root@172.16.200.91's password: [vi-admin@vma ~][172.16.200.91]$ sudo vifp addserver esx03.peanuts.local root@esx03.peanuts.local's password: [vi-admin@vma ~][172.16.200.91]$ vifpinit esx03 [vi-admin@vma ~][esx03]$ esxcfg-vmknic -l Interface Port Group/DVPort IP Family IP Address Netmask MAC Address MTU Type vmk0 Management Network IPv4 172.16.200.90 255.255.255.0 00:50:56:71:f8:b6 9000 STATIC vmk0 Management Network IPv6 fe80::250:56ff:fe71:f8b6 64 00:50:56:71:f8:b6 9000 STATIC vmk1 vMotion IPv4 172.16.200.91 255.255.255.0 00:50:56:77:35:17 9000 STATIC vmk1 vMotion IPv6 fe80::250:56ff:fe77:3517 64 00:50:56:77:35:17 9000 STATIC
And the server is now reachable via the FQDN and the vmk’s appear in proper order. If you have the ability, perform a netstat -na on the NAS to verify connections are coming from the vmk0 address.
Problems and Resolution
I’ll update the post with corrections, but with different configurations, we may run into different issues.
| Problem | Resolution |
| NAS shows connections from both vmk0 and vmk1 addresses | This may require one final reboot to clear. The reboot completed after creating vmk0 still had vmk1 as designated for management traffic. Those connections may live until no longer used or another reboot. This should only be an issue if NFS permissions are set to specific IP addresses. |







[...] http://www.kendrickcoleman.com/index.php?/Tech-Blog/esxi-41-kickstart-install-wip.html http://www.gavinadams.org/blog/2010/07/19/esxi-41-and-the-9000-byte-mtu-on-vmk0 [...]
hey great posted i followed these steps to get jumbo frames working in my ISCSI environment .. cheers!
Hey,
I followed your steps on the esxi side. However, after i did that i can mount the NFS share and create a folder ( to check if i can write ) However, it takes hell lot of time to read the contents of the NFS datastore
I have a two vmkernel ports on my ESXi 4.1 server.
ESXi server configuration:
vmk0 – mtu 1500 and used for management traffic only. A separate VLAN is used for the management.
vmk1 – mtu 9000 and used for NFS only. Separate VLAN.
vSwitch has 9000 mtu.
esxcfg-nics -l show mtu 9000
On the switch – The VLAN on switch is configured for mtu 9000. The mtu on the port channel to NFS server is MTU 9000.
NFS interface has 9000 mtu setup.
What do you think I may be doing worng here??
Servers used – Cisco UCS
Switch – Cisco 6504
Storage EMC NS120
Appreciate your help.
Hi Mohit,
It sounds like there may still be a packet size problem somewhere between the ESXI host and the EMC. I’m not familiar with the Cisco switch or the EMS NAS, but slow performance can be indicative of mismatched MTUs.
The first thing I would try is to verify that the MTU is properly set, and operational, between the endpoints. If your NFS is UNIX/Linux based, use the ping command to the ESXi host to verify the MTU.
In Linux, it would be something like: ping -s 8500 -M do hostname
Where -s is the packet size and the “-M do” ensures the don’t fragment flag is set. You should get microsecond (less than 1ms) response times. If you see something like:
… icmp_seq=1 Frag needed and DF set (mtu = 9000)
That will indicate an issue.
If the NFS host doesn’t have a similar ping command, setup a host on the same VLAN as the ESXi vmkernel and NFS server. Make sure it also has a MTU of 9000 set, and ping the ESXi and NFS servers from there.
For Windows, the ping command would be: ping -l 8500 -f hostname
In know for some switches you may need to restart in order for the MTU to take affect. What version of IOS are you running, and what supervisor do you have?
So i looked at my oncfiguratiosn and i saw the i had vmk0 for management on mtu 1500 and vmk1 for nfs on mtu 9000. The moment i chnaged the vmk0 to mtu 9000 i could access the datastore. however, i am still not sure if i am getting end to end jumbo frame traffic.
You mentioned that ” Management Network – vmk0 – Management traffic – managed via vCenter / vMA, and as lowest vmk, used by NFS for storage on the same subnet.”
I have my storage on a different subnet (vmk1) should me NFS traffic go through vmk1?? and not worry about vmk0.
Glad you got it working. My example is basically to help people test in a lab and to see what the process is for changing the MTU. Please follow VMware’s design guidelines for production environments.
Normally this have storage traffic onto a separate physical NIC, and do the same with host traffic. In my home config, I have 2 or 3 NICs teamed together for all use (vMotion, storage, and the various networks for the guests).
To verify, see if the command on the switch “sh controllers ethernet-controller iface” (where iface is the interface of the NAS or ESXi host) and see what shows up for different MTU sizes.
I don’t have a Cisco switch available to test jumbo frames on – poor only 2924′s here.
Well i think i spoke too soon. When i deleted vmk0 and recreated it with mtu 9000 i could access the datastore. But after sometime i did not loose connectivity but i could not access data on the datastore.
her eis my config
vmk0 192.168.50.75 mask 255.255.255.0 m 9000 gw 192.168.50.1
vmk1 192.168.112.9 mask 255.255.255.0 m 9000 gw 192.168.50.1
VLAN 112 – 192.168.112.0/24 mtu =9216
VLAN 50 -192.168.50.0/24 mtu =1500
both on vSwitch0 with two 10G Nics.
When i recreated vmk1 I could access my datastore. however this is not stable. Atleast i feel so.
vSwitch has mtu 9000
nics have mtu 9000
I want my esx servers to use vmk1 to mount NFS Share. however it looks like its going through the .50.75 interface. I noticed this when i changed te right on the nfs share to only 112. it mounted the share but it could not write to it. I had to add 50.75 and then it could write to it.
What could be the problem???
[...] ping -s <size> <destination IP> Here’s a good blogpost about MTU – check the [...]
I’m running ESXi 4.1
I created my vSwitches and modified the MTU using the PowerCLI, executing the following:
esxcfg-vswitch.pl -m 9000 vSwitch2
Is that acceptable
Great article. What if you have more than one vSwitch. Where will the new vmk be created? Is there a way to specify vSwitch in the CLI?
great write up dude. The only tip I give, depends on if you have the Lic for this, but it pays to dump the vswitch concept and create a distributed switch, under distributed switch you can manage all the VLan and port groups quite well.
as a personal favorite can create a direct link to the dedicated nic for man or NFS traffic into two separate port groups, one for service console the other for (the rest), talking home lab style here
. Anyway, when you create the new vmkernel it asks for which port group to assign (in distributed switch).
And if you want to migrate it to a virtual switch its a one click job.
Great article, helped me alot
Very simple and effective.
Thanks dude ! Help me a lot !