How to remove the icon "Safely remove hardware" from the statusbar of a VM

• Power off the virtual machine
• Open "Edit settings"
• Select the "Options" Tab
• Select "General" –-> "Configuration Parameters"
• Click "Add Row"
• Add a field named: devices.hotplug with value: FALSE
• Power on VM

For more information read the article Remove the icon "Safely remove hardware"

How to reset root password in ESXi 4.x & 5.x

This guide is unsupported from VMware, so do it on your own risk.
First download a live Linux boot CD. In my case I downloaded Knoppix.
Then you can burn the ISO to make a bootable cdrom or use a tool like Live Linux USB Creator to make a bootable Linux USB stick.
Boot with above Linux boot CD or USB and enter
# fdisk -l
to find the disks resident on the server.
Find the partition holding the file state.tgz and mount it. In my case it was /dev/sdb5 so I used the commands:
# mkdir /mnt/disk
# mount /dev/sdb5 /mnt/disk
# cd /mnt/disk
# ls -al
# cp state.tgz state.tgz.bak
# cd /ramdisk
# mkdir temp
# cd temp
# tar zxf /mnt/disk/state.tgz
# ls -al
# tar zxf local.tgz
# cd etc
# vi shadow
Use the above command to edit the shadow file holding the root password.
Delete all characters between the first and second : character so that you erase the root password.
Write back the shadow file and quit vi using the command :wq
Finally put everything back using the commands:
# cd ..
# rm -rf local.tgz
# tar zcf local.tgz *
# chmod 755 local.tgz
# rm -rf /mnt/disk/state.tgz
# tar zcf /mnt/disk/state.tgz local.tgz
# ls -al /mnt/disk/
# umount /mnt/disk
# shutdown -r now

Linux 2.6 kernel-based virtual machines experience slow disk I/O performance in ESXi

As of the Linux 2.6 kernel, the default I/O Scheduler is Completely Fair Queuing (CFQ). The scheduler is an effective solution for nearly all workloads.
With the release of Linux 2.6, the kernel has these schedulers as configurable options:
Completely Fair Queuing (cfq): CFQ is the default under many Linux distributions. CFQ places synchronous requests submitted by processes into a number of per-process queues and then allocates time slices for each of the queues to access the disk. The length of the time slice and the number of requests a queue is allowed to submit depends on the I/O priority of the given process. Asynchronous requests for all processes are batched together in fewer queues, one per priority.
NOOP (noop): NOOP is the simplest I/O scheduler for the Linux kernel based upon the FIFO queue concept. The NOOP scheduler inserts all incoming I/O requests into a simple FIFO queue and implements request merging. The scheduler assumes I/O performance optimization will be handled at some other layer of the I/O hierarchy.
Anticipatory (anticipatory): Anticipatory is an algorithm for scheduling hard disk I/O. It seeks to increase the efficiency of disk utilization by "anticipating" synchronous read operations.
Deadline (deadline): The goal of the Deadline scheduler is to guarantee a start service time for a request. It does this by imposing a deadline on all I/O operations to prevent starvation of requests.
The default scheduler will affect all disk I/O for VMDK and RDM-based virtual storage solutions. In virtualized environments, it is often not beneficial to schedule I/O at both the host and guest layers. If multiple guests use storage on a filesystem or block device managed by the host operating system, the host may be able to schedule I/O more efficiently because it is aware of requests from all guests and knows the physical layout of storage, which may not map linearly to the guests' virtual storage.
Testing has shown that NOOP or Deadline perform better for virtualized Linux guests. ESX uses an asynchronous intelligent I/O scheduler, and for this reason virtual guests should see improved performance by allowing ESX to handle I/O scheduling.
To implement this change, please refer to the documentation for your Linux distribution.
Note: All scheduler tuning should be tested under normal operating conditions as synthetic benchmarks typically do not accurately compare performance of systems using shared resources in virtual environments.
For example, this change can be implemented by:
The scheduler can be set for each hard disk unit. To check which scheduler is being used for particular drive, run this command:
cat /sys/block/disk/queue/scheduler
For example, to check the current I/O scheduler for sda:
# cat /sys/block/sda/queue/scheduler
[noop] anticipatory deadline cfq
In this example, the sda drive scheduler is set to NOOP.
To change the scheduler on a running system, run this command:
# echo scheduler > /sys/block/disk/queue/scheduler
For example, to set the sda I/O scheduler to NOOP:
# echo noop > /sys/block/sda/queue/scheduler
Note: This command will not change the scheduler permanently. The scheduler will be reset to the default on reboot. To make the system use a specific scheduler by default, add an elevator parameter to the default kernel entry in the GRUB boot loader menu.lst file.
For example, to make NOOP the default scheduler for the system, the /boot/grub/menu.lst kernel entry would look like this:
title CentOS (2.6.18-128.4.1.el5)
root (hd0,0)
kernel /vmlinuz-2.6.18-128.4.1.el5 ro root=/dev/VolGroup00/LogVol00 elevator=noop
initrd /initrd-2.6.18-128.4.1.el5.imgWith the elevator parameter in place, the system will set the I/O scheduler to the one specified on every boot.

How to activate cdp and lldp in a vSwitch in ESXi

From esxcli
to activate both in vSwitch0 enter:
esxcli network vswitch standard set -c both -v vSwitch0
to list cdp and lldp status enter:
esxcli network vswitch standard list -v vSwitch0

Forcing a link state up or down for a vmnic interface on ESXi 5.x

To change the link state of the physical interface from the Management Network vmkernel log in to the ESXi 5.0 host using Tech Support Mode with root account privilege.
Change the link status of the uplink vmnic with one of these commands:
esxcli network nic down -n vmnicX
esxcli network nic up -n vmnicXWhere X is the vmnic number (for example,vmnic0)

Issues related to updating the VMware vCenter Server Appliance

The vCenter Server Appliance update fails to install the update to 5.0 U1 and the log file /opt/vmware/var/log/vami/updatecli.log displays the following error message:
"ERROR: Not enough space on disk to migrate embedded database."
The solution to this problem is this:

• Create a new virtual disk with size 20GB and attach it to the vCenter Server Appliance.
• Log in to the vCenter Server Appliance's console and format the new disk as follows:
• At the command line, type, "echo "- - -" > /sys/class/scsi_host/host0/scan".
• Type, "parted -s /dev/sdc mklabel msdos".
• Type, "parted -s /dev/sdc mkpartfs primary ext2 0 22G".
• Mount the new partition under /storage/db/export:
• Type, "mkdir -p /storage/db/export".
• Type, "mount /dev/sdc1 /storage/db/export".
• Repeat the update process. 

You can remove the new disk after the update process finishes successfully and the vCenter Server Appliance is shut down.

VMware Security Patching Guidelines for ESXi and ESX

Please see the following KB article from VMware

Upgrading VMware Update Manager to version 5.0 Update 1 fails while updating SQL Express instance

Upgrading VMware Update Manager 4.x or 5.0 to VMware Update Manager 5.0 Update 1 fails.The setup fails while updating the SQL Server Express instance.
The installed version of SQL Server Express is 10.50.2500.0, which is the same as the redistributable version bundled with vSphere 5.0 Update 1.
This can be checked with SQL Management Studio. Right-click the SQL Server instance and select Properties to verify the version.
This issue can occur if the version information for SQL Server Express in the registry is incorrect. The vSphere installer checks this registry key and compares it to the version string of the bundled SQL Express setup:
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Microsoft SQL Server\VIM_SQLEXP\MSSQLServer\CurrentVersion
If these version strings do not match, the vSphere installer will attempt to upgrade the database even though the database version is already up to date.
To resolve this issue run regedit and navigate to:
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Microsoft SQL Server\VIM_SQLEXP\MSSQLServer\CurrentVersion
Change the value of the key to match the version string of the redistributable Microsoft SQL Express installer. For example, the version string is 10.50.2500.0 for SQL 2008 R2 SP1 Express.
Click OK and close the Registry Editor.
Update VMware Update Manager again to verify.
For more information read the following article from VMware KB

How to fix the VM autostart problem in vSphere 5 Update 1

Activate the ESXi shell
Login and enter this command to obtain a list of VMs
vim-cmd vmsvc/getallvms
Note the number of each VM you want to autostart
Create a script like this one:
vim-cmd vmsvc/power.on 50
sleep 30s
vim-cmd vmsvc/power.on 15
where you put a line for each VM you want to autostart, using the VM number you note earlier.
Save this script in a datastore folder and make it executable:
chmod 777 /vmfs/volumes/datastore1/scripts/autostart.sh
add a line to your /etc/rc.local file to call autostart.sh:
/vmfs/volumes/datastore1/scripts/autostart.sh

How to determine the ESXi installation type

ESXi installed on a host can be one of these types:
Embedded
Installable
PXE
To determine the type of ESXi installation:
Connect to the host via SSH.
Run this command:
# esxcfg-info -e
You see an output similar to:
boot type: visor-thin
You can determine the ESXi type based on the output of this command.
For example:
visor-thin indicates an installable deployment
visor-usb indicates an embedded deployment
visor-pxe indicates a PXE deployment
For more information read the following article from VMware

How to clear the Hardware Status warnings/errors in vCenter Server

To clear the warnings/errors from the Hardware Status tab:.  

• Go to Hardware Status tab and select the System event log view.
• Click Reset event log.
• Click Update. The error should now be cleared.
• Select the Alerts and warnings view.
• Click Reset sensors.
• Click Update. The memory should now be cleared.

If the error is not cleared, connect to the host via SSH.
Restart the sfcdb service.
To restart the service in ESXi, run this command:
services.sh restart
To restart the service in ESX, run this command:
service sfcbd restart
Click Update. The error should now be cleared.
For more information read the following article from VMware.

ESX/ESXi hosts fail with a purple diagnostic screen and report the error: #PF Exception(14)

When new worlds are created, an integer is incremented. When this integer overflows, the kernel panics and fails with a purple diagnostic screen. In ESXi, new worlds are created for all processes because there is no service console operating system. Therefore, this number increments much faster in ESXi than ESX. In ESXi, this issue occurs when the system has been running for a very long time (over a year) without a reboot and has been actively creating processes. In ESX classic, it is almost impossible to hit this threshold.
To workaround this issue, reboot the host. Rebooting the host restarts the counter and eliminates the risk of any failure.

To avoid a reboot, you can check to determine if your system is at risk.

To determine if your system is at risk, run this script in the ESXi command line:
highWID=$(vsish -e ls world | sed 's!/$!!' | sort -n | tail -n 1)
let microFull=highWID/7400
echo ${microFull}

If this script returns a value close to 100,000, it is recommended to schedule a reboot.

How to change the boot order of a virtual machine using vmx options

In ESXi/ESX, choose the boot device using the advanced virtual machine options bios.bootOrder and bios.hddOrder.
Note: These settings override the boot order that you might have set in the virtual machine's BIOS previously.
The virtual machine's boot order can be set to any virtual NIC via ethernetX, where X is the number of the device. For example, ethernet0 or ethernet5. It can also be set to hdd, cdrom, or floppy. If set to cdrom or floppy there are multiple devices, the virtual machine tries them sequentially until it finds one to boot from. If bios.bootOrder is set to hdd, you also have to define bios.hddOrder and set a device (for example, scsi0:3 or ide1:0) to boot from.
You can also configure a list of devices. Ensure to put the list into quotation marks and seperate the devices with commas. For example:
bios.bootOrder = "ethernet5,ethernet2,hdd,cdrom,floppy"
bios.hddOrder = "scsi2:2,scsi0:1,ide1:0"
In this example, the virtual machine tries to boot with ethernet5. If there is nothing to boot from, try ethernet2. If that fails, try from the disks (hdd) defined in hddOrder, then all cdroms, and finally from all floppys.
Unlike BIOS, you can choose from all available NICs and disks, but there is a maximum of 5 NICs and 8 disks that can be used in a boot order list. If you move a bootOrder/hddOrder configured virtual machine to a host that is not running on ESXi/ESX, it might not use the boot order you expect it to upon the next restart.
To configure bootOrder for a virtual machine using the vSphere Client:

• Shut down the virtual machine.
• Click the virtual machine in the Inventory.
• Click the Summary tab for that virtual machine, then click Edit Settings.
• In the Virtual Machine Properties dialog, click the Options tab.
• Under Advanced, click General.
• Click Configuration Parameters.
• Click Add Row.
• Create two new rows.
• Enter bios.bootOrder to the Name column and enter the devices in the Value column.
• Enter bios.hddOrder to the Name column and enter the devices in the Value column.
• Click OK to save the changes.

For more information read the following article from VMware

How to convert .GHO files to .VMDK

Ghost treats virtual disks as images. You can image a machine to a virtual disk (create a vmdk file instead of a .gho file), and you can restore a machine from a vmdk file. While performing any imaging operation GHO is the default file format of ghost
VMDK files cannot be opened in Ghost explorer, You can mount a VMDK file by using ghost with switch –ad=, once it is mounted can be used in all ghost operation.
You may want to use a Physical machine's Ghost image in vmdk or otherwise, you may want to use a vmdk to prepare a Physical machine .
By performing following simple commands you can convert the GHO files to VMDK and a VMDK file to GHO.
To convert from GHO to VMDK
ghost32 -clone,mode=restore,src=my.gho,dst=myimage.vmdk -batch -sure
To convert from VMDK to GHO spliiting into 100MB chunks
ghost32 -clone,mode=create,src=my.vmdk,dst=myimage.gho -batch -sure -split=100
There are some more switch available

• vmdktype: Used for specifying the VMDK file type , which can be Sparse or Flat
• vmdksplit: Used for splitting the VMDK image
• vmdksize: Used in specifying the size of vmdk file
• vmdkAdapter: Specifying the type of disk adapter for created vmdk

To create a VMDK file form machine directly
Ghost32 –clone,mode=create,src=1,dst=myimage.vmdk  -vmdk -sure
To restore VMDK image on machine directly
Ghost32 –clone,mode=restore,src=myimage.vmdk,dst=1  -vmdk -sure
For more information read the following article.

Installing the HA Agent fails on all hosts, except one

Please read the following article from VMware KB.

After a host power failure, vMotion fails with the error: Module is not loaded

This issue occurs because the vMotion module fails to load automatically after a power failure. To resolve this issue, you must re-enable vMotion after the host power failure.
To re-enable vMotion:
Click the host in vCenter Server and then click the Configuration tab.
Click Properties on the vSwitch where the vMotion VMkernel port group is located.
Click the vMotion port group and click Edit.
Deselect the vMotion Enabled option.
Click OK and then click Close.
Connect to the host using SSH.
Run this command to verify if the vMotion module is loaded:
vmkload_mod -l | grep migrate
If the above command does not return any values, run this command to load the module:
vmkload_mod migrate
Run this command and verify if the vMotion module is now loaded:
vmkload_mod -l | grep migrate
Run this command to restart services:
services.sh restart
Repeat Steps 1 to 3 and select the vMotion Enabled option. This enables vMotion.
Migrate virtual machines to another host.
Reboot the host.
Run this command to verify if the vMotion module loads properly:
vmkload_mod -l | grep migrate
You must see an output similar to:
# vmkload_mod -l | grep migrate
migrate                  2    252
For more info read the following article from VMware

Performing common virtual machine-related tasks with command-line utilities

Please read the following article from VMware KB

Adding a USB device to the virtual machine fails in ESXi 5

After upgrading an ESXi 4.1 host to ESXi 5.0, you are unable to add a USB device to the virtual machine. The USB controller has been added to the virtual machine, but the USB device is not available.
This issue occurs if hostd loads before the USB Arbitrator in ESXi 5.0
To workaround this issue:
Connect to the host using SSH as the root user.
Open the /etc/init.d/usbarbitrator file using the vi editor.
Locate this line:
# chkconfig: 3 70 70
Change this line to:
# chkconfig: 3 17 83
Save and close the file.
Run these commands on the host:
chkconfig usbarbitrator off
chkconfig usbarbitrator on
Reboot the host.
Run this command to stop hostd service:
/etc/init.d/hostd stop
Run this command to stop the usbarbitrator service:
/etc/init.d/usbarbitrator stop
Run this command to start the usbarbitrator service:
/etc/init.d/usbarbitrator start
Run this command to start hostd service:
/etc/init.d/hostd start
For more information read the following article from VMware.

Upgrading from vCenter Server 4.1 to 5.0 fails

Upgrading from vCenter Server 4.1 to 5.0 fails and an exception is thrown while executing SQL script. This issue occurs if an index named INDX_TIME_ID in the VPX_HIST_STAT1 table was not deleted in a previous upgrade and continues to exist. The script to upgrade the table fails because of the index's constraint on the TIME_ID column.
To remove the lingering index on the table:
Launch SQL Server Management Studio and Connect to the SQL instance of the vCenter Server database.
Take a backup the vCenter Server database.
To back up the vCenter Server database, right-click the database and click Tasks > Back Up.
Expand the Databases folder.
Click the vCenter Server database name.
Click the New Query button on the toolbar. A blank query window appears.
Enter this SQL statement in the blank query window:

    DROP INDEX VPX_HIST_STAT1.INDX_TIME_ID

Execute the statement by pressing the F5 key or by clicking the ! Execute button on the toolbar.
For more information read the following article from VMware KB.

How to correctly remove a LUN from an ESX host

Please read the following article from VMware.