How to Enable Jumbo Frames for Hyper-V Guests

Default implementations of TCP/IP typically set the MTU (maximum transmission unit) size at 1500 bytes. This is to ensure optimal interactions with legacy systems and Internet pathways. Using larger values for MTU (jumbo frames) can increase the speed of large data transfers because, when all goes well, there are more useful data bytes per overhead header and encapsulation bytes.

This isn’t always the case, however. If any link in the chain cannot handle the larger MTU, IP segments must fragmented. If this occurs, additional overhead is required in order to track fragmentation. Data crossing the Internet will almost always be limited to 1500 MTU. Starting with 1500 as the initial MTU virtually guarantees that fragmentation will never occur but will not be the most efficient size in all scenarios. TCP/IP does contain a mechanism that allows endpoints to determine the lowest common MTU across a given link, but it is not a requirement and the multi-path nature of TCP/IP could easily render these determinations moot. Fragmentation and dropping of oversized packets can quickly cause endpoints with large MTUs to become much slower than endpoints set at the default of 1500, regardless of the speed of the connecting equipment.

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 (, 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


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.


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.


Altaro Hyper-V Backup
Share this post

Not a DOJO Member yet?

Join thousands of other IT pros and receive a weekly roundup email with the latest content & updates!

61 thoughts on "How to Enable Jumbo Frames for Hyper-V Guests"

  • Gary Gemmell says:

    Love these articles – well presented – well laid out and I learn something new evertime – didnt know you generally needed to reboot a switch after jumbo enable. Always do it as a habit but interesting to know anyway!

    Great stuff!!!

    Loving the articles – pertinent , educational without being verbose and having the yawn factor that so many others have!!!

  • spitfire says:

    I have a question: Since I’m planning to use three Hyper-V hosts in my home lab, two of which will have only 1 NIC -if I enable jumbo frames on the Hyper-V host, will that affect virtual switch, or guest interfaces? VMs are meant to communicate with client OSes, which won’t have jumbo frames enabled.

    • Eric Siron says:

      Once it’s enabled on the physical adapter, it’s available to the switch. If the virtual adapters are then enabled for jumbo frames, then they can pass them as well. If your VMs don’t need jumbo frames, then don’t enable it on their virtual adapters.

  • Alain Zahm says:


    has this to be set at Hyper-V level or for each VM? In other words if PMTUD is not ENABLED at Hyper-V level will it work?

  • AVP says:

    Thank you for this post.

    What if my physical NIC on the host has MTU set to 9198 (since Layer 2 switch it is connected to has default Jumbo Frame setting of 9216) and Hyper-V’s Virtual Switch only allows up to 9014 – will this cause issues? Or is better to set the physical NIC MTU to match 9014 of the Hyper-V’s Virtual Switch?

    • Eric Siron says:

      Remember that not everyone calculates frame size the same way. I recognize 9216 for a switch and 9014 for an operating system, but I have never seen anyone use 9198 before. But, Windows is the endpoint, so as long as it doesn’t use a frame size larger than any other component, things will work. You can use Wireshark to watch for evidence of fragmentation over the switch.

Leave a comment or ask a question

Your email address will not be published. Required fields are marked *

Your email address will not be published. Required fields are marked *

Notify me of follow-up replies via email

Yes, I would like to receive new blog posts by email

What is the color of grass?

Please note: If you’re not already a member on the Dojo Forums you will create a new account and receive an activation email.