Yellow Bricks

by Duncan Epping

3.5

NIC Teaming load balancing does not work with global vSwitch configuration on ESX 3.5

· ·

A week ago a colleague contacted me about the fact that he had issues with load balancing on “Virtual Port ID”. Only a single NIC was utilized while running over 10 VMs on a single host. When changing the order of the NICs the traffic would flip over but again no load balancing. I remembered a KB article from months ago and pointed him to the article. Yesterday on the VMTN Community someone reported a similar issue with his ESX 3.5 environment. I referred to the article again and it solved the problem. Might be worth checking your setup in terms of load balancing. Is your second NIC actually being used? And if not here’s a short description of the problem and the solution:

Source

  • Symptom: NIC Teaming load balancing properties do not take effect with global vSwitch configuration settings.
  • Resolution: Override the load balancing order at the port group level, under Policy Exceptions, select the checkbox and choose the proper load balancing from the dropdown menu. Please note that this workaround only works until the next reboot of ESX.

RE: max num vCPU’s Malaysia VMware Communities

· ·

I was just reading this article on the Malaysia VMware Communities website I’ve read a couple of article on their website that didn’t make sense but this this time I’m going to respond cause it might set people on the wrong foot. Anyone is of course entitled to their own opinion and views, but please reread your article and check the facts before you publish, especially when your blog is featured on planetv12n. A short outtake of the blog:

If we refer to the current version which is ESX 3.5 u3, the maximum number of Vcpu per ESX server is only 128 per ESX Servers. Personally, I think the number of Vcpu per ESX servers is too minimal. Imagine if we do run a servers with 4 or 8 physical CPU sockets and we consolidate 40 : 1 Physical server in our virtualization environment, we will hit to the bottleneck on maximum numbers of Vcpu per ESX servers but not due to the CPU consumption

Reading this short section one might think, why reply it makes sense? No, it doesn’t make sense at all:

  • The current limit isn’t 128, it’s 192 vCPU’s.
    So even with a 40:1 ratio and all VMs provisioned with 4 vCPU’s you wouldn’t hit this limit. Read the max config guide, it’s the bible for virtualization consultants.
  • But even more important: co-scheduling and over provisioning will impact performance. With most VM’s running 2 or even 4 vCPU’s scheduling will be almost impossible even with the relaxed co-scheduling techniques ESX is using these days. In other words, please don’t use multi vCPU VMs as a standard, you can read more on c0-scheduling here.

The author asked VMware to bump up the max number of vCPU’s. Now for a VDI environment this can and will be useful I think. Again if you are hitting the number with a 16 core machine, you might need to reconsider your provisioning strategy.

I expect the number to go up… especially after watching Stephen Herrod’s keynote at VMworld Europe 2009.

vCenter tasks time-out or ESX disconnects?

· ·

I just received an email from a fellow consultant about a customer which had vCenter tasks time-out every once in a while. At times also ESX hosts got disconnected for no apparent reason at all. He discovered the following article by Richard Blythe aka VMware Wolf: ESX disconnects randomly or when doing VI client tasks from VC, task randomly timeout after a long idle time. Richard created a list of issues/errors that might be related to this issue:

  • ESX disconnects randomly from VirtualCenter
  • ESX disconnects when performing VI Client tasks from VirtualCenter.
  • Tasks randomly timeout after a long idle time
  • “An error occurred communicating to the remote host” pops up.

The article refers to an issue with vCenter Update 3 in combination with firewalls using state-ful inspection. The problem occurs because of SOAP timeouts, and this behavior did not exist in VC 2.0.x or 2.5 GA, as they used a different mechanism to communicate with ESX. The official KB article hasn’t been released yet but a temporary workaround has been published by Richard. If you run into any of the before mentioned issues head over to Richard’s website and try out the workaround until the fix or official KB article is released.

Patches for 3.5

· ·

VMware just released 9 new patches for ESX 3.5:

  • ESX350-200901401-SG – PATCH – Security – KB 1006651 – Updates VMkernel VMX hostd. But most important fix that this patch containts definitely is: VMware ESX and ESXi 3.5 U3 I/O failure on SAN LUNs, and LUN queue is blocked indefinitely. For a full description of this issue, see http://kb.vmware.com/kb/1008130.
  • ESX350-200901402-SG – PATCH – Security – KB 1006652 – Security Update to ESX Scripts
  • ESX350-200901404-BG – PATCH – Critical – KB 1006654 – Updates VMware Tools
  • ESX350-200901405-BG – PATCH – General – KB 1006655 – Updates VMware-esx-lnxcfg
  • ESX350-200901406-BG – PATCH – General – KB 1006656 – Updates Kernel Source and VMNIX
  • ESX350-200901407-BG – PATCH – General – KB 1006657 – Updates Pegasus
  • ESX350-200901408-BG – PATCH – Critical – KB 1006658 – Updates SATA Drivers
  • ESX350-200901409-SG – PATCH – Security –KB 1006659 – SNMP Security Update
  • ESX350-200901410-SG – PATCH – Security – KB 1006660 – Security Update for libxml2

There’s one “patch” released for ESXi (installable and embedded) 3.5:

  • ESXe350-200901401-O-SG – PATCH – Security – KB 1006661 – KB 1006662 – KB 1007058 – Firmware Update
    If you are using SRM in combination with ESX besure to read the KB1006661 cause this patch contains several fixes related to SRM.

There’s also a whole bunch of 3.0.x patches released, so if you’re still running 3.0.x besure to look into these new patches.