Yellow Bricks

by Duncan Epping

bug

Scripts release for Storage vMotion / HA problem

· ·

Last week when the Storage vMotion / HA problem went public I asked both William Lam and Alan Renouf if they could write a script to detect the problem. I want to thank both of them for their quick response and turnaround, they cranked the script out in literally hours. The scripts were validated multiple times in a VDS environment and worked flawless. Note that these scripts can detect the problem in an environment using a regular Distributed vSwitch and a Nexus 1000v, the script can only mitigate the problem though in a Distributed vSwitch environment. Here are the links to the scripts:

Once again thanks guys!

Workaround for: ESX(i) 4.1 Password Issue

· ·

As many of you already know there is an issue with the encryption mechanism of ESX(i) 4.1. When passwords are used which are longer than 8 characters the password will be truncated after the 8th character. As such during authentication only the first 8 characters are used. In other words if you have  a 10 character password you will only need to type the first 8 characters correct and the rest can be completely random.

The KB article that was published yesterday contains a workaround to change this behaviour. I recommend everyone to read the article and implement this workaround when your password policy describes passwords longer than 8 characters.

vSphere 4.1: Datacenter.QueryConnectionInfo failed?

· ·

When I was installing vSphere 4.1 ESXi I ran into a problem. I received the following error when I added the ESXi host to my cluster:

Call “Datacenter.QueryConnectionInfo” for object “yellow bricks” on vCenter Server “W2K8-001” failed.

Although the error didn’t make much sense I had the feeling it had something to do with name resolution(This KB article gave a hint I guess). After I added my dns suffix on my NIC it worked. Problem solved.

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.

Issue with Update 1 and COS Agents

· ·

I wrote this article after the KB was release but forgot to click “publish”. Those planning to upgrade their vSphere environment to Update 1 please read the following:

KB Article 1016070

Issue
Upgrading ESX 4.0 to 4.0 U1 fails or times out and rebooting the host results in a purple diagnostic screen

Who is affected
Customers using VMware vSphere 4 upgrading to Update 1 with 3rd party management agents running.

To identify whether you have a 3rd party management agent installed:

  1. Log into the ESX host as root.
  2. Run the esxupdate query command.
  3. Anything listed under New packages: may be a 3rd party management agent in the service console.

Note: Consult your hardware vendor documentation for specific package names that are installed in the service console.

Solution

To avoid this issue, prior to the update, disable all 3rd party management agents running on the ESX 4.0.0 server before applying the update.

Note: The 3rd party management agents can be enabled after the upgrade is completed.

If you have already updated the ESX host, do not reboot the ESX host. Open a support request with VMware support. For more information, see How to Submit a Support Request.
WARNING: Rebooting the host means the host has to be reinstalled because it is not recoverable after a reboot.

WARNING: If you have virtual machines running on local storage, they may not be retained if you reinstall ESX 4.0 as a result of this issue. Contact VMware Support for assistance in recovering those virtual machines.