VMware Cloud Community
FrankGrey
Contributor
Contributor

VMWare ESXi Installation Failing - Help!

Hello,

Although I have used VMWare Workstation in the past, I am new to VMWare ESXi, so please bear with me on this. I will try to be as detailed as possible. I recently purchased components to a server that I would like to try installing ESXi on as a test bed before rolling it out to other hardware. Unfortunately, things are not going as I would have hoped, ESXi 3.5 is not installing. The message I am getting is not terribly helpful either - something along the lines of required hardware not being detected. But let's start at the beginning, with the hardware:

- Motherboard: Supermicro X8DTi

- Processors: 2x Intel Xeon E5520

- Memory: 6x 2GB Crucial DDR3-1333 ECC Unbuffered SDRAM

- Hard Drive: 1x SATA Hard drive (Western Digital branded, 640GB - Caviar Black series)

- Optical Drive: 1x SATA Optical Drive (LG branded)

- USB Mouse/USB Keyboard/LCD monitor plugged in to VGA-OUT on motherboard

Basically, my procedure was:

1. Connect all hardware, make sure it passes POST and verify everything is seen in BIOS

2. Put DVD containing an image of VMWare ESXi 3.5 in to DVD drive and watch it load, then fail to install.

Interestingly, the failure message states I should write down hardware information before asking for help, but it doesn't seem like something worth posting here... it incorrectly detected my motherboard, and also generated a serial number of something like "1234567890". I thought posting the actual hardware in the box might help more.

Any assistance you could give would be greatly appreciated.

Tags (4)
Reply
0 Kudos
23 Replies
filbo
Enthusiast
Enthusiast

Dave.Mishchenko wrote:

If you enable the sticky bit on the file - i.e chmod +t 72.ipmi then ESXi will back up the file to the system state then you don't have to worry about the system firmware files (which would be replaced the next time you patch your host).

This is correct but incomplete...

It's important that the sticky bit be turned on before you modify the file. It's a signal to the kernel (VisorFS filesystem) to automatically create a backup at the time of modification. The shutdown-and-backup script determines which files to save by the presence of these kernel-created backups.

I would recommend turning on the sticky bit and leaving it on, in case a future implementation changes this to be interpreted at shutdown-and-backup-changes time rather than file modification time.

>Bela<

Reply
0 Kudos
filbo
Enthusiast
Enthusiast

Compitem wrote:

This is the strange behavior i have. I do the following on the "72.impi" file:

...

"chmod +t 72.ipmi"

"sed -i '/Exec/s/^/return $ # disable IPMI\n\n/' 72.ipmi"

...

and reboot the host with my VI-Client. After booting i look again in the "72.ipmi", seems to be all ok.

Then i reboot again, the same way with my VI-Client. Look again, the file looks like as it has never been altered.

That is strange...

Look at the modification times on /etc/vmware/init/init.d/7?.* (1) before you make any changes, (2) after changes and before reboot, (3) after first reboot, (4) after 2nd reboot. I write "7?.*" so you will see both 72.ipmi (which you are changing) and some other files that you aren't changing.

72.ipmi should only be changing when you change it; the modification times (as shown by `ls -l`) should only change when you edit the file.

What do you see?

>Bela<

Reply
0 Kudos
Compitem
Contributor
Contributor

Now i find it out. In "backup.sh" only files are saved which has a dot and a pound (.#72.ipmi).

You cannot "touch" the file in the dir. Its not allowed. This is only for information.

-


For those who have the same Problems on ESX4i:

1. Set the Sticky Bit on 72.ipmi

2. Alter the file how it is discribed with the "sed" command. (sed -i '/Exec/s/^/return $ # disable IPMI\n\n/' 72.ipmi)

3. Take the VI-Client and alter Extended Configuration. The last point "VMKernel". I took a screenshot.

4. Reboot. Works like a charm.

-


I say thank you to all the people who have helped me, especially the Tip with the kernel "did the trick"...

Reply
0 Kudos
filbo
Enthusiast
Enthusiast

Compitem wrote:

Now i find it out. In "backup.sh" only files are saved which has a dot and a pound (.#72.ipmi).

You cannot "touch" the file in the dir. Its not allowed. This is only for information.

That's the file permanence mechanism for ESXi. When you modify a file that has the sticky

bit, VisorFS saves the original as .#filename and makes a copy to hold your modifications.

When you shut down, backup.sh scans the system for those .# files and saves copies of the

modified files (with ".#" removed from the names).

This rename-and-copy only happens when you modify a file while it has the sticky bit set;

otherwise it just modifies the in-core copy without leaving backup.sh a note to save it.

To make matters even stranger, backup.sh only looks for .#* files in /etc (or at least that's

what it did on ESXi 3.5 -- I haven't checked 4.0). So you can fool around however you want

in other directories, the changes will not persist across a reboot. (Of course you can more

directly subvert the mechanisms by modifying local.tgz manually. Files in that tarball will

overlay files of the same name from other tarballs, without being restricted to /etc.)

For those who have the same Problems on ESX4i:

1. Set the Sticky Bit on 72.ipmi

2. Alter the file how it is discribed with the "sed" command. (sed -i '/Exec/s/^/return $ # disable IPMI\n\n/' 72.ipmi)

3. Take the VI-Client and alter Extended Configuration. The last point "VMKernel". I took a screenshot.

4. Reboot. Works like a charm.

Hmmm... I didn't know about the IPMI setting in Extended Configuration. Having set that, did

you really need to do steps 1 & 2 at all?

>Bela<

Reply
0 Kudos