VMkernel Networks, Jumbo Frames, and ESXi 4

February 12th, 2010 by jason Leave a reply »

Question:  Can I implement jumbo frames on ESXi 4 Update 1 VMkernel networks?

Answer:  Who in the hell knows?

You see, the ESXi 4.0 Update 1 Configuration Guide states on page 54:

“Jumbo frames are not supported for VMkernel networking interfaces in ESXi.”

Duncan Epping of Yellow Bricks also reports:

“Jumbo frames are not supported for VMkernel networking interfaces in ESXi. (page 54)”

One month after the release of ESXi 4 Update 1, Charu Chaubal of VMware posted on the ESXi Chronicles blog:

“I am happy to say that this is merely an error in the documentation. In fact, ESXi 4.0 DOES support Jumbo Frames on VMkernel networking interfaces. The correction will hopefully appear in a new release of the documentation, but in the meantime, go ahead and configure Jumbo frames for your ESXi 4.0 hosts.”

Shortly after, Duncan Epping of Yellow Bricks confirms Charu Chaubal’s report that jumbo frames are supported on ESXi VMkernel networks.

Now, nearly two months after Charu’s clarification and three months after the release of ESXi 4 Update 1, the documentation remains dubious on page 54 stating that jumbo frames are not supported on ESXi 4 VMkernel networks which is a direct contradition to a VMware ESXi blog.

I opened a Business Critical Support SR with VMware on the question.  I was told by VMware BCS that jumbo frames are NOT supported on ESXi 4 Update 1 VMkernel networks and a reference was made to the documentatation on page 54. 

Our dedicated VMware onsite Engineer escalated and I was then told ESXi 4 Update 1 DOES support jumbo frames on VMkernel networks, making reference to Charu’s article.

Hey VMware, which is it?  If this is a documentation mistake, why are you dragging your feet in getting the documentation updated two months after a VMware employee discovers the error and blogs it?  Waiting for the next release of ESXi?  Unacceptable!  You update the public documentation as soon as you discover the error and be damned sure your BCS support Engineers know the right answer!  Do you know how much companies pay for BCS?  You owe your customers the correct answer.  If misinformation comes as a result of a known documentation error, SHAME ON YOU!  Architecture and design decisions are being made daily on this information or misinformation, which ever it may be.

Update 2/23/10:  Toby Kraft (@vmwarewriter on Twitter) will be updating the documentation by next week.  Thank you Toby!

Update 3/1/10:  VMware has updated their documentation to reflect currently supported configurations.  Thank you VMware (and Toby)!

Advertisement

No comments

  1. Ceri Davies says:

    That’s not terribly different to a case I raised late last month where ESX was swapping out VMs while in the “high” memory state, again completely contrary to the documentation.

    My plea that this was either a software or a documentation bug and that one of the above should be corrected was on deaf ears.

  2. Dave Convery says:

    About a year ago, I had a customer call support with an issue in one of their ESXi servers. The tech actually said that ESXi was not for enterprises and they should convert everything over to ESX. I had just spent two months in a Plan and Design only to have it ruined by an uninformed support “engineer”. I had to go back and re-write the design for ESX.

    VMware needs to keep their front line techs up to date at all times. It sounds like they are just looking things up in the documentation and spouting off what they believe is true.

  3. duncan says:

    it is supported(see my revised article) and ESXi is Enterprise ready. If any support engineer tells you differently please let me know.

    http://www.yellow-bricks.com/2009/12/10/esxi-lessons-learned-part-2/

    http://www.yellow-bricks.com/2009/12/19/esxi-lessons-learned-2-revised/

  4. jason says:

    Thanks Duncan, I’ve made an addition referencing your most recent article.

  5. jason says:

    BCS Support Engineer did tell me jumbo frames were not supported. That was the catalyst of this article.