You might need to do this if you have an ip address conflict or for some other reason where going through all the guests would be a time consuming and laborious process.

With ESX and ESXi version 4 onwards that command was removed, so the below ash script will allow you to either list the VM’s on a host, or if you use it with an argument it will search for a mac address or part of a mac address.

This script will allow you to search and find a mac address and tie that to a guest name. The script needs to be run on the ESX or ESXi host/s

run it from the command line like below

#./macfinder.sh   < no arguments to list all registered VM’s

or

#./macfinder.sh 00:50:56:00:00:00  < with argument to find specific or part of mac address

___________________________ shell script below —————————

#!/bin/ash
# searches current registered vm’s then uses that list to find macAddresses of those

# then greps output for desired mac or part of mac address

vim-cmd vmsvc/getallvms | awk ‘{print $1″:” $2}’ | grep -v Vmid > /tmp/allvms
for lines in `cat /tmp/allvms`do

id=$(echo $lines | awk -F: ‘{print $1}’)

name=$(echo $lines | awk -F: ‘{print $2}’)

mac=$(vim-cmd vmsvc/device.getdevices $id | grep macAddress)

if test $1then
echo $name $mac | grep $1

else echo $name $mac

fi

done

rm -rf /tmp/allvms

The cause of the problem was a iscsi lock caused by 2 hosts trying to write to the same store at the same time.

This was evident from messages on the ESX hosts from the error message: vprob.vmfs.heartbeat.timedout and referencing one of the volumes on our ISCSI storage.

This was causing the entire ESX host to have connectivity problems as well as affecting the guests that resided on that volume.

Because the host and guests were not accesible through vSphere, we were unable to remove the volume or power cycle the guests.

After much digging around and with the help of VMWare support we understood that the cause of the problem was a lock on that filesystem, and to fix the problem we ran vmkfstools -L lunreset /vmfs/devices/disks/volumename…

This removed the lock which was caused by 2 hosts trying to write to the same volume at the same time and causing a iscsi lock.

Very painful, but happy to have the cluster back up and running.

After much debugging on the network side, thinking that perhaps there was a misconfigured NIC with the wrong VLAN config, the problem was still happening.

So ssh’ing onto the host, I started to trawl through the log files, and came across the below in the /var/log/vmkwarning file:

Feb 17 13:44:19 vminfraboxvmkernel: 18:00:00:11.865 cpu4:4222)WARNING: NMP: nmp_DeviceAttemptFailover: Retry world failover device “naa.6090a028004f243d08ab44c26687e3dd” – issuing command 0×410002074040
Feb 17 13:44:19 vminfrabox vmkernel: 18:00:00:11.865 cpu4:4222)WARNING: NMP: nmp_DeviceAttemptFailover: Retry world failover device “naa.6090a028004f243d08ab44c26687e3dd” – failed to issue command due to Not found (APD), try again…
Feb 17 13:44:19 vminfrabox vmkernel: 18:00:00:11.865 cpu4:4222)WARNING: NMP: nmp_DeviceAttemptFailover: Logical device “naa.6090a028004f243d08ab44c26687e3dd”: awaiting fast path state update…

This was occuring repeatedly every half hour and the entries above filled the logs solidly for about 2 minutes continuously every half an hour.

After doing some digging on the google, I found out that ESX4 has a bug whereby if you have a duff or old connection to an iSCSI LUN – perhaps one that no longer exists – but you never rescanned to remove it – when the host tries to check the paths every 30 minutes, it finds this duff connection and goes through the motions of trying to find failover paths. The bug is that this causes very brief network loss to your guests.

The fix for me was to simply re-scan my adapter, which removed the old mapping to one of our removed LUNS’s and the problem went away.

So follow the below steps to ensure your guests power on automatically on host startup.

Open vSphere Client

In the left hand pane, highlight your choosen host, then click the configuration tab in the main pane.

Click Virtual Machine Startup/Shutdown under the software Section.

Click Properties in the top right hand corner of the main pane.

Then check Allow virtual machines to start and stop automatically with the system, then change the startup order of your guests in the box below as appropriate.

If you want all to startup with the host, then move them all up to automatic startup.

Now when your host restarts, your guests will come up automatically as well.

However, with VMWare things changed a little. Virtual Switches dont provide the same level of functionality as current physical switches (unless you spend lots of money)

As far as I know basic VMWare switches dont have a command to tell you the arp table and the associated hosts / port.

So what can you do if you get for example an IP address conflict where you only know the mac address of the conflicting host?

Well, I found a superb script which interrogates an ESX host and lists the guest name, alongside the MAC address.

Its as follows – for ease create a shell script and paste the below in.

When you run it you will get output like this:

win2k8server2.vmx
 /vmfs/volumes/49a2845c-2b4514f9-09bc-001f295db10d/win2k8server2/win2k8server2.vmx
displayName = “win2k8server2″
ethernet0.generatedAddress = “00:50:56:97:20:dd”

win2k8server1.vmx
 /vmfs/volumes/49ae5e8c-bb3c9818-e2dd-001d295db10d/win2k8server1/win2k8server1.vmx
displayName = “win2k8server1″
ethernet0.generatedAddress = “00:50:56:97:31:98″

Script as follows

——————————-

#!/bin/bash

for COUNT in $(vmware-cmd -l); do
echo `echo $COUNT|awk -F’/’ ‘{print $6}’`
echo ” “`echo $COUNT`
echo ” “`cat $COUNT|grep “displayName”`
#MAC Address may refer to “Address” instead of “generatedAddress”
echo ” “`cat $COUNT|grep “generatedAddress”`
echo
done

————————

It would seem that when the storage failed, VMWare didnt get a chance to cleanly shut the hosts down, although it did shut them down. This resulted in the virtual swap file being left on the filesystem, so that when the storage was available once again there was a orphaned vswp file. This was preventing the hosts from being powered on, because VMWare was seing this, thinking the hosts were on already and throwing an error.

The fix, manually removing the vswp file sorted this out.

I did it by ssh’ing onto the box, navigating to the datastore and the virtual machine directory, and then for safe measure, moving the vswp file to another name – .vswp.bak Then when I tried to power the machine on, it recreated the vswp file and the machine happily powered back on. Once this was up, I fully deleted the vswp.bak file to tidy things up, and we were back in business.

Note, we’ve also found that you might need to delete / move the hlog file too…

Error parsing the server “YOUR SERVERS IP” “clients.xml” file. Login will continue, contact your system administrator.

You click OK and they you get:

The type initializer for ‘VirtualInfrastructure.Utils.HttpWebRequestProxy’ threw an exception.

You click OK and vSphere fails to launch

After upgrading to Windows 7 you may have suddenly read horrible threads that tell you VMWare vSphere client will not work. Well its all lies. Its true that it wont work out the box, but a quick tweak and you’ll be good to go in minutes.

Follow these steps, which will get you up and working again in a flash.

1:) Obtain a copy of .NET framework system.dll from a non Windows 7 box. In my case I took it from a Windows 2003 server. The file is located at %SYSTEMROOT%\Microsoft.NET\Framework\v2.0.50727 which for me was c:\windows\Microsoft.NET\Framework\v2.0.50727

2:)Create a folder (call it Lib+) in your VMWare vSphere installation to put this file. I created the following (on a 32bit installation) C:\Program Files\VMware\Infrastructure\Virtual Infrastructure Client\Launcher\Lib+

A quick summary, you should now have a folder called C:\Program Files\VMware\Infrastructure\Virtual Infrastructure Client\Launcher\Lib+ with a file called System.dll from a non windows 7 installation of .NET Framework v2.0.50727

3:) Now go into C:\Program Files\VMware\Infrastructure\Virtual Infrastructure Client\Launcher and edit the file VpxClient.exe.config in textpad or notepad etc..

Add in the following lines just before the final line (which reads </configuration>)

<runtime>
  <developmentMode developerInstallation=”true”/>
</runtime>

Save this file

Now create a batch file called whatever you choose – I choose vSphereLauncer.cmd but it doesnt matter, and put the following in it (on the assumption that the paths are correct etc..) – Note it is 2 seperate lines.

SET DEVPATH=%ProgramFiles%\VMware\Infrastructure\Virtual Infrastructure Client\Launcher\Lib+
“%ProgramFiles%\VMware\Infrastructure\Virtual Infrastructure Client\Launcher\VpxClient.exe”

Thats it!

Run your newly created batch file, and you should no longer get that irritating message!

If this post was useful, please click some of the Ad blocks which help me to keep this site running. Thanks!

Once you have the vSphere CLI, change the the directory where the vSphere binarys are installed, i.e /usr/bin

To configure the communities do the following:

vicfg-snmp.pl –server <hostname> –username <username> –password <password> -c <com1>.

Replace <com1> with the community name you wish to set. Each time you specify a community with this

command, the setings you specify overwrite the previous configuration. To specify multiple communities,

separate the community names with a comma.

For example, to set the communities public and internal on the host host.example.com, you might type

vicfg-snmp.pl –server host.example.com –username user –password password -c public, internal.

To configure the SNMP agent traps do:

vicfg-snmp.pl –server <hostname> –username <username> –password <password> -t <target

address>@<port>/<community>.

Replace <target address>, <port>, and <community> with the address of the target system, the port number

to send the traps to, and the community name, respectively. Each time you specify a target with this

command, the settings you specify overwrite all previously specified settings. To specify multiple targets,

separate them with a comma.

For example, to send SNMP traps from the host host.example.com to port 162 on target.example.com using

the public community, type

vicfg-snmp.pl –server host.example.com –username user –password password -t

target.example.com@162/public.

Enable the SNMP agent by typing

vicfg-snmp.pl –server <hostname> –username <username> –password <password> –enable.

Send a test trap to verify that the agent is configured correctly by typing

vicfg-snmp.pl –server <hostname> –username <username> –password <password> –test.

The agent sends a warmStart trap to the configured target.

To configure the SNMP agent for polling do:

vicfg-snmp.pl –server <hostname> –username <username> –password <password> -p <port>.

Replace <port> with the port for the embedded SNMP agent to use for listening for polling requests.

If the SNMP agent is not enabled, enable it by typing

vicfg-snmp.pl –server <hostname> –username <username> –password <password> –enable.

And there you have it SNMP on ESX4i.

First you will need to make the neccesary hole in the ESX firewall, do this by running as root

esxcfg-firewall -e snmpd

Then configure snmp. You will need to do this appropriatly for your environment, but edit /etc/snmp/snmpd.conf

Once you have done this, type

chkconfig –level 2345 snmpd on

To enable snmpd on startup init levels 2, 3, 4 and 5.

Then either reboot or type

/etc/init.d/snmpd start

Jobs a goodun.

Well VMWare has esxtop

Commands when in esxtop are:

s - change the screen update delay – values from 0.1 seconds upwards

If you hit space, it will immediatly update the screen.

f or F allows you to add additional fields / columns

c allows you to view CPU resource utilization

m allows you to view memory resource utilization

d allows you to view storage adapter resource utilization

u allows you to view storage device resource utilization

v allows you to view VM resource utilization

n allows you to view network resource utilization.

All these commands can help you to identify any potential bottlenecks or areas you need to make some additional resource changes.