How to Enable Jumbo Frames for Hyper-V Guests

Hyper-V’s virtual switches and the virtual switch ports they expose to virtual machines are no different than any other TCP/IP implementation. They begin life with an MTU of 1500, and will happily stay there unless you increase the limit. If you intend to raise that limit, it is worth your time to ensure that enough of the traffic flowing across a virtual port can benefit sufficiently to justify an MTU increase.

A common positive reason to increase MTU would be if you want to connect an iSCSI target directly to a virtual machine. Note that it is quite possible to leave virtual ports at the default of 1500 while “plugged in” to a virtual switch with jumbo packets enabled. You might have an externally facing virtualized web server that you want to leave at 1500 that shares a virtual NIC with a virtualized backup server that drops data on an iSCSI device each night. Setting the virtual switch and the backup server’s virtual NIC to 9000 MTU allows backup data to flow as efficiently as possible; leaving the web server’s virtual NIC at 1500 MTU allows your web server to communicate with external clients without fear of fragmentation. If necessary, you could add a second virtual NIC to your web server and set its NIC to 9000 MTU and instruct it to use that port to communicate with a back-end SQL Server.

There are three overall steps necessary to ensure proper configuration.

1. The physical connecting hardware must support jumbo packets and this feature must be activated. Almost all switches require a power cycle after jumbo frames have been enabled.
2. Hyper-V’s virtual switch must have jumbo frames enabled.
3. The individual virtual NIC must have jumbo frames enabled.

Enabling jumbo frames on a physical switch varies by manufacturer so you’ll need to consult their documentation to change that. This article also does not cover changing non-Windows virtual machines. For the Hyper-V server and Windows virtual machines, the process is almost identical.

Native Hyper-V or Server Core – Virtual Switches

When you create a virtual switch on a NIC, that NIC effectively disappears from easy discovery in NETSH. It’s there, but it can be difficult to discover and work with. Note that if you chose the option to share the virtual switch with the management operating system, what you see in IPCONFIG and NETSH is a virtual NIC that was created on the virtual switch, not the virtual switch itself.

To change the MTU on virtual NICs:

1. Download NVSPBIND (http://archive.msdn.microsoft.com/nvspbind), unblock it, and copy it to the Hyper-V host.
2. Run: Nvspbind /o * vms_pp
   This will show all of the adapters. Those with a setting of “enabled” is/are your virtual switch(es). Note these names.
3. Run: Nvspbind /n “<<adapter name from step 2>>”
   Among other things, this will show you the GUID of the adapter. On the title bar of your command prompt, right-click and go to Edit->Mark. Highlight the GUID without the opening and closing brackets. Press Enter to copy it to the clipboard.
4. Run: REGEDIT. Navigate to HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlClass{4D36E972-E325-11CE-BFC1-08002BE10318}. Right-click on that key and choose “Find…”. Paste the copied GUID into the search box and click “Find Next”.
5. In the located sub-key, find “*JumboPacket”. Change its entry to 9000 (some documentation indicates 9014; 9014 is the “proper” size but both settings seem to have the same effect).
6. If other adapters were found in step 2, repeat for them starting from step 3.

If you don’t have or don’t want to get NVSPBIND, it is possible to step through the registry entries in step 4 to locate the virtual adapters. In the Linkage subkey is an UpperBind value. A virtual switch will only contain “VMSP” in this field.

Server Core Virtual Machines– Virtual NICs

It is possible to use the above steps for the virtual switches, although it is probably not the most efficient way. If that is the method you choose, then in step 2 use: “nvspbind /o * *”. You’ll need to decide based on your findings which adapter(s) to change. Do not modify the loopback address. NETSH is probably the   preferred tool; its steps are below.

1. Run: netsh int ipv4 sh int
   This will list all adapters bound to IPv4.
2. Run: netsh int ipv4 set subinterface “<<name from step 1>>” mtu=9000 store=persistent

GUI

From within a GUI, the only thing that changes is which adapters you set. The process is the same for adapters in the parent partition and in a Windows guest VM.

1. Open Network and Sharing Center. Click “Change Adapter Settings”.
2. Right-click the adapter you want to modify and click “Properties”.
   
   
3. Click “Configure”.
   
   
4. On the Advanced tab, find “Jumbo Packet” in the list box and set it to 9014. OK all the way out.
   
   

Testing

In most cases, you don’t need to reboot any Windows machine, host or virtual, in order for these changes to take effect. However, if the testing doesn’t work and you’re sure that every single endpoint and physical switching equipment has been set properly, that is the first thing to try.

At a command prompt from within the virtual machine, run:
ping <<target IP>> -f –l 8972

If the results mention fragmentation, then some setting is not working properly.