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.

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.

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.

• Download the Vista 64 Bit driver for the Intel 965 (in my case Lenovo laptop)
• Unzip the software
• Right click properties on the “setup.exe”
• Click on the Compatibility tab and select mode to “Windows Vista Service Pack 2″ and select “run this program as an administrator” at “privilege level”
• Click “Ok”
• Run the setup and reboot

So far I haven’t experienced the issues anymore…

A professional associate of mine shared screen captures of a variety of Hyper-V failures. My associate was evaluating the performance of a server running Hyper-V. The test was a workload derived from VMmark. When he repeatedly saw VMs blue-screening in Hyper-V during the test, he started capturing video of the events. Apparently the publicly available version of Hyper-V is unable to run VMs reliably. Is this why TechNet and MSDN went down on 4/30/09?

Symptoms:

• After one of the following, a Virtual Machine appears as being registered on two ESX Servers:
  • A VMotion fails to complete correctly or times out in VirtualCenter
  • A DRS issue where virtual machines are VMotioned automatically in quick succession
  • When a machine is powered on during VMware HA failover.
  • The Service Console on an ESX host is low on memory starving the vpxa process
• In VirtualCenter, you see the virtual machine as appearing on one ESX Server for a few seconds, then it seems to be on the other.
• The virtual machine may appear to jump back and forth among different ESX hosts.

I’m not going to copy/paste the solution cause the KB article will probably change over time, but it’s most definitely worth looking into… it does sound like something that can happen to all of us.

VMware ESX 3.5, Patch ESX350-200904201-SG: Updates VMX RPM
Issues fixed in this patch (and their relevant symptoms, if applicable) include:

• A critical vulnerability in the virtual machine display function might allow a guest operating system to run code on the host. The Common Vulnerabilities and Exposures Project (cve.mitre.org) has assigned the name CVE-2009-1244 to this issue.

Fixing your broken installation is fairly easy:

To use this patch, download it from the attachment, gunzip it, then go to your /usr/lib/vmware/modules/source directory. Untar all of the files. Apply the patch with “patch -p1″. After the patch has applied, re-tar all the files. Then, run “vmware-modconfig –console –install-all” again, under Linux 2.6.29, and it should now work.

Go to the VMTN Forums and download the patch if you are having trouble getting the VMware Workstation kernel modules compiled correctly!

Adding a dependency to the VirtualCenter service so that it waits for SQL Express remedies this.

To create a service dependency:

1. Click Start > Run.
2. Type services.msc and press Enter.
3. Locate the SQL Express instance for VirtualCenter. For example, SQL Server (SQLEXP_VIM).
4. Open the SQL Express instance and note the Service Name. For example, MSSQL$SQLEXP_VIM .
5. In the Run dialog, type Regedit.exe and press Enter. Browse to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\vpxd .
6. Double-click the DependOnService key and add the Service name using the name identified in step 4.
7. Close Regedit .
8. Go back to the Services Panel and open the SQL Server properties.
9. On the Dependencies tab, verify the VMware VirtualCenter service is listed as depending on the SQL service instance.

As you can see the solution is fairly easy. Keep in mind that you need to be running the SQL Server locally on the vCenter server for this to work, especially for larger environments I wouldn’t advise running both on the same box. For SMB environments this should work just fine.

• 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.