During the installation of VirtualCenter the following error code was presented “25036”. With no further message the installation is cut-off. After a close inspection it seemed that there already were a couple of SQL Express 2005 services installed, the software was removed and the services were still there but disabled. I guess for some reason the removal of SQL 2005 Express wasn’t successful. The installation procedure seems to have a hard time overwriting the registry values or changing the old values. This problem can easily be solved by manually deleting that specific service in the registry. (HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services)
Bugs
vmkping results in “syscall version mismatch (compiled: 0x7616c4e3, kernel: 0x50f63116)”
When troubleshooting a VMotion problem on an unpatched ESX 3.0.2 update 1 host today I wanted to use vmkping. This constantly resulted in the following error message:
syscall version mismatch (compiled: 0x7616c4e3, kernel: 0x50f63116)
I did not find any useful info on google so I checked the VMware knowledge base, maybe some over at VMware can read my mind or it’s a pure coincidence they just updated the following KB article, it seems to be a bug which is fixed in ESX-1002424. It’s actually mentioned in the release notes… I should read those more often I guess.
ESX 3.5 and weird DRS/HA behaviour…
During the last couple of ESX 3.5 and VC 2.5 implementations I encountered some weird DRS/HA behavior:
- During the reboot of a VM ESX decided to vmotion the VM, as you can imagine this took a lot longer than normal due to the memory being excessively active.
- When the DRS Affinity Rules in a two cluster node is set to “seperate” two specific virtual machines VMware has a hard time relocating a VM when a host goes into “maintenance mode”. I can imagine why this happens but it’s definitely not something that’s suppose to happen in my opinion. It’s a Admin initiated manual action it should overrule all affinity settings.
So let me hear which weird behavior you noticed with ESX 3.5 / VC 2.5….
VirtualCenter 2.0.2 Update 3
VMware just announced VirtualCenter 2.0.2 update 3:
Resolved Issues include:
Virtual Machine Management Issues
PR:219126 – Virtual Machine Alarms Not Triggered This release fixes an issue where VirtualCenter alarms are not triggered when the alarm conditions are met.PR:225357 – Host and Virtual Machine Alarms Stop Updating Over Time This release fixes an issue where some alarms that are configured for a virtual machine can fail to update. This issue is usually encountered after the virtual machine has changed power state.
PR:163019 – Virtual Machines Do Not Show Correct Status This release fixes an issue where the status indicators of some virtual machines do not accurately reflect the virtual machine’s status. This issue usually occurs after a restart of the VirtualCenter Server.
Licensing Issues
R:229629 – VirtualCenter Does Not Correctly Display New License Format This release fixes an issue where earlier versions of VirtualCenter are not able display licenses from license files issued since the release of VirtualCenter 2.5. On versions of VirtualCenter before 2.0.2 Update 3, the license files appear to install normally but log warnings such as “Chunk ‘desc=ESX Server Enterprise’ was not well formed, skipping” in the log files when license files of the new format are displayed in VirtualCenter.
The release notes aren’t online yet, so we will have to wait for a more detailed view on what has changed in this release.
Performance counters bug for the cluster?
Today I noticed the following in a ESX 3.5 and Virtual Center 2.5 environment: When you check the performance of the memory(past day) on the cluster the minimum and maximum is way more than expected. In this case the minimum is 66,9% and the maximum 106,01%. This cluster has around 64GB of memory and there’s only around 30GB assigned, nowhere near the 66,9% or the 106,01% for that matter. Anyone who can confirm this behavior or even better explain it. I’m afraid it’s a bug…