I've sucessfully installed ESXi 4.0 (later updated to u1) on a H8DiI-F and H8Di3-F.

With default BIOS settings, and with many different BIOS settings, too.

But I'm using (for VMware OS partitions) HDDs at Adaptec RAID controllers, or partitions on USB sticks.

The VMFS datastore partitions I've placed on HDDs at Adaptec RAID controllers, or at onboard SAS controllers (of the H8Di3+-F).

The onboard SATA controller seems to be recognized as an "SB700" (and not precisely that one which is integrated into the chipset / SP5100 chip, perhaps a similar successor of the SB700). Additionally only four of the six SATA ports are available with this driver.

(I don't trust in 100% reliability of the onboard SATA controller usage, therefore.)

(By the way: we don't have to talk about PATA. That's outdated. Disable it.)

But I've used an additional HDD at the SATA controller for backing-up/transferring VMs (formatted as VMFS, too). All of this was done by vSphere Client techniques.

(So it could be possible that initial installation to HDD at SATA controller is working, anyway - but I didn't tested that ever.)

(Be sure "OnChip SATA Type" is "Native IDE" (BIOS default) <- Advanced Chipset Settings, SouthBridge Configuration.)

Perhaps you're choosing one of the not supported two SATA ports? SATA0 should be recognizable (is "third master", the 5th of all 8 IDE).

spaceinvader

DSTAVERT wrote:

It is up to the manufacturer to certify the MB/System/Component. Supermicro is well represented on the HCL. Why choose something not on the list?????

Because someone want to choose boards that fits to his demands! (Not all customers are interested in using prefabricated high price and low equiped solutions of others. - But, of course, they have some risks for trouble...)

Chosing 100% VMware certificated solutions is for unskilled workers, "setup droids", or similar.

And this board is running with ESXi 4 in general. My systems are working.

The AMD chipset SR5690/SP5100 is developed especially for virtualization solutions. But it's new. So you have to calculate running into problems.

spaceinvader

a627tqt wrote:

turns out it's bad memory.  with 16 dimms it's going to take a while to track down, but that's easy.  Thanks for the assist.  I actually discovered it by booting memtestx86+ and it hung up almost immediately!  pulled a bunch out, rebooted and esxi boots!

I'm curious:

Are you sure you've bad memory modules?

Or may it be a problem of fully populated slots? (With 16 modules there are special issues, like power consumption and line amplifiers / buffers etc..)

(I would expect problems, even if it should run corresponding to technical facts sheets. Especially with cheap or mixed modules.)

spaceinvader