I recently implemented ESX 3.5 on my SunFire 40 Server (dual AMD single core CPUs); replacing ESX 3.02. When it boots it gets hung up for at least thirty minutes (no exaggeration) trying the connect to the ipmi drivers: ipmi_si - KCS, ipmi_si - SMIC, and ipmi_si - bt at different I/O ports.
I have two questions:
Is there a way to disable IPMI; or at least these checks for it?
With my Server evidently not supporting the Intel Management specification (IPMI); is this going to cause any problems? The system seems to operate fine except for the painfully long boot process.
I was a 3.5 beta tester and this occured with the beta's as well. Thanks in advance for any assistance!
Unload OpenIPMI driver that VMware loads, rpm -qa|grep -i IPMI should find it. I have an older ML350 G3 we try to blow up with new toys, and ESX 3.5 on it, gets the same error, but since the SMBus on the server is not recognized, it waits a second or two, and goes on.
Unload OpenIPMI driver that VMware loads, rpm -qa|grep -i IPMI should find it. I have an older ML350 G3 we try to blow up with new toys, and ESX 3.5 on it, gets the same error, but since the SMBus on the server is not recognized, it waits a second or two, and goes on.
I both grep'd the installed RPM's for ipmi (and IPMI) and dumped the entire list and manually examined it and could not find a related package (nothing with ipmi, openimpi, etc...). So, perhaps it's embedded within something else like a VMware related package. After having a good cup of coffee I realized it's simply a driver with a startup script. So I turned it off with the following chkconfig command (as root):
chkconfig --level 0123456 ipmi off
That took care of it and my system now boots lightening fast 🙂 All is well.
My bad? I am so used to using hardware vendor agents, which usually load separate IPMI, I was thinking VMware had a separate RPM for it. The chkconfig trick is correct.
