1 person found this helpful
Try swapping your CPUs around so that the current 2nd processor is in slot 1 & vice versa. There are issues with CPUs having different steppings and the manufacturers are not paying attention to this. As far as they know it's a VMware issue. The steppings either need to be identical or the newest stepping needs to be in the first slot.
If that doesn't work you can try following a few things from the 3650 install guidelines:
If a CD/RW drive is installed in your system, follow these steps before installing virtual machines:
Log on to the ESX server as root and make a copy of the file /boot/grub/grub.conf.
Edit grub.conf and look for the text "hda=ide-scsi" at the end of the kernel load image.
Restart the server.
To install the Advanced System Management (ASM) device driver, complete the following steps:
Insert the VMware ESX Server 3.5.0 operating system CD into the CD or DVD drive and mount the drive.
Go to the VMware/RPMS directory on the CD and install libusb-0.1.6-3.i386.rpm and libusb-devel-0.1.6-3.i386.rpm.
rpm -ivh libusb-0.1.6-3.i386.rpm
rpm -ivh libusb-devel-0.1.6-3.i386.rpm
Download the latest version of the ASM device driver from the IBM Web site at http://www.ibm.com/systems/support/management/.
If this is an upgrade to an existing Remote Supervisor Adapter II daemon, the previously installed Remote Supervisor Adapter II daemon must be removed. Do not try to upgrade the RPM with the upgrade (-U) switch. To install the RPM, use the following command:
rpmbuild --rebuild ibmusbasm-1.XX.src.rpm
To make the RPM file, which builds and installs the Remote Supervisor Adapter II daemon or support software for the IBM Remote Supervisor Adapter II, use the following commands.
rpm -ivh ibmusbasm-1.XX.i386.rpm
1 person found this helpful
The error seems to be related to ACPI and bus scanning.
Are you SAN booting?
If so can you bring pathing down to a single path to see if your boot target is doing ok? I assume you did the installs with only single path.
Also, physically remove all but one of the HBA needed to boot from the SAN.
If you are not SAN boot. Then remove the HBAs from the server temporarily. This will baseline the server with out attached VMFS volumes or associated storage devices to get to it.
Last idea is to build an ESX 3i boot USB key and boot that. That is always a useful way to see if the issue is related to a SAN subystem (if SAN boot) or local drive / array issue, and limit the testing down to ESX and associated CPU and RAM. If you have an RSA you can simply boot this via the Image transfer option within the RSA remote boot device options.
This is the oddest one ever but the fix was to remove and swap around the 2 cpu's boot once, then swap them back. Spooky - these cpus are not pins but like contact 2 contact, pad things the only thing I can think of is slight oxidization had occured.
I have done the above on all three servers and all work fine now no problems after multple reboots, it looks like all the error messages I was getting were just a load of rubbish, even the logs were pointless to the fact - lick one's finger and test the wind!