Steve Harris

This process to install vmware ESXi 4.1 on to a USB key from an Apple Mac (OSX) was adapted from the following article which explains the process for previous versions of ESXi http://blog.scottlowe.org/2009/01/08/creating-a-bootable-esxi-usb-stick-on-mac-os-x/. The difference being the filename and location of the image on the ESXi 4.1 CD.

1. Download the ISO and mount in Finder
2. Copy the file imagedd.bz2 from the mounted ISO to a location on your hard disk
3. Insert the target USB key in to your Apple Mac
4. Open a terminal window
5. Run diskutil list, locate the USB key in the list for this example we will say it is /dev/disk5
6. Run diskutil unmountDisk /dev/disk5 it will disappear from Finder but will still be accessible from the command line
7. Run bzcat imagedd.bz2 | dd of=/dev/disk5, you will need to specify the location of the .bz2 file you copied in step 2
8. Wait for the process to finish, it may take some time
9. When the prompt reappears check bytes were successfully transferred, if not check your previous commands
10. Run diskutil eject /dev/disk5 to eject the disk, it can now be removed from the Mac
11. Insert the USB key in to the server/pc you are going to run ESXi and power it up.

It is important to note this will boot in to ESXi directly and is not the installer. Once started your can set the root password and configure using the menu system.

The same process could be used for installation on to SD Cards, but check the hardware compatibility lists on vmware.com.

Symptoms

The VMWARE vSphere client closes or crashes when you right click on a host and select Import Machine.

Cause

You probably have an older version of the VMWARE client such as VI Client 2.5 installed for administration of older ESX installations.

There is a DLL conflict documented in http://www.vmware.com/support/vsphere4/doc/vsp_vcc_41_rel_notes.html, although it describes a Visual C++ Runtime error which I did not receive.

Resolution

The solution documented in the release notes works though which is to remove (although I suggest rename) the following files located in C:\Program Files\VMware\Infrastructure\Virtual Infrastructure Client\Launcher:-

• libeay32.dll
• ssleay32.dll

Once renamed/removed if you have the vSphere client open, close the client and open it again otherwise simply open the vSphere client. The vConverter utility should now run when you use Import Machine.

Disclaimer: The SSH commands used in this article could potentially cause problems if used incorrectly. I take no responsibility for their use on your system and I had a VMware representative on the phone guiding me through the process. Obviously if you if you do not have a support contract this may be your only option.

Regardless the procedure below resolved the issue without interruption to service/running virtual machines (VMs) on the host.

Symptoms

When trying to remove an empty resource pool from vCenter one or more hosts do not accept the removal request stating that the pool is not empty. The following error can be seen scrolling at the bottom of the vSphere Client when connected directly to the host:-

Error during the configuration of the host. Can not delete non-empty group: poolx

Cause

Corruption of the pools.xml file stored on the ESX host.

Resolution

This can be carried out while running VMs are on the host:-

• Ensure the pool is empty;
• Using an SSH client (putty works) connect to the host in question and login with root or equivalent;
• Change folder by entering cd /etc/vmware/hostd followed by return/enter;
• Search the pools.xml file for the resource pool (it may help to rename the pool to something easy to find) by entering cat pools.xml | grep –I poolname e.g. cat pools.xml | grep –I broken;
• If found copy the current pools.xml file so that you have a backup cp pools.xml pools.backup;
• Now delete the pools.xml file by entering rm pools.xml confirm with y when prompted;
• Restart the vmware management agent by entering service mgmt.-vmware restart;
• Wait for the service to restart and monitor the resource pools in the VI Client,

Within a couple of minutes vCenter should have pushed out a new pools.xml and this time the resource pool should be gone.