I noticed at a few customer sites that the Performance tab of VirtualCenter was getting sluggish but never got the chance to really pinpoint the problem. A couple of days ago user “jterpstr” posted about this on the VMTN forum and it seems that the old rows aren’t deleted from the database for some reason. The table grows to an enormous amount of rows which causes some queries to become unresponsive or very very slow. For more info and a possible solution keep track of this topic om the forum. Thanks to the guys in this thread for pinpointing the problem and narrowing it down to a possible cause.
Today I encountered a weird problem. When I started the installation of VirtualCenter 2.0.2 on a Windows 2000 Server I received the following error notification:”Setup cannot continue. The “VMware VirtualCenter Server 2.0″ requires Update 1 Rollup for Windows 2000 SP4. Please see KB article 816542 at http://support.microsoft.com/kb/816542/.”
I checked the server but the patch was installed, so I rebooted the machine to be sure the installation of the update was completed but no luck. I reinstalled the patched and tried to install VC but again no luck. Next thing to do was check the VMTN forum and luckily someone already encountered the same weird problem and they received the following fix from VMware support:
************ Problem ***********
Update from VC 2.0.0 to VC 2.0.1 not possible.
Error message that Update Rollup 1 is not installed.
************ Root Cause (if known) ***********
Wrong registry check of installer.
************ Solution ***********
Replace NTDLL.DLL by KERNEL32.DLL in the registry:
HKLM\SOFTWARE\Microsoft\Updates\Windows 2000\SP5\Update Rollup 1\Filelist\0]
“BuildDate”=”Thu Jan 13 10:09:36 2005”
Before installing VCB and connecting the proxy host to the SAN you should disable automount via diskpart(cmd, diskpart, automount disable, automount scrub). When you don’t disable automount Windows will signature all “incoming” disks. When this happens the VMware hosts will not recognize the VMFS volumes anymore. But fortunately you can re-label the luns as VMFS.
Check with “fdisk -lu” what the current ID value is of the volumes, it’s “SFS” if Windows wrecked it. Write all the devices down and label them again as VMFS:
fdisk /dev/sd? (? the letter for that specific volume)
128 (disk alignment, check your SAN manual for the correct value, 128 is correct in most cases…)
Now rescan the HBA devices, esxcfg-rescan vmhba0 etc etc.