Watch out for vicfg- commands also. If you are using the RCLI tools for managing ESX 3i, then the esxcfg- tools are now prefixed with vicfg- although the esxcfg- prefix still works.

Here are a few examples of some VMkernel parameters which can be interrogated.

[root@esx1host vmware]# esxcfg-advcfg -g /Misc/BlueScreenTimeout
Value of BlueScreenTimeout is 0

[root@esx1host vmware]# esxcfg-advcfg -g /Misc/HostName
Value of HostName is esx1.vmlab.net 

The question is, how much is configurable? To figure out what is configurable, we recommend that you look in the directory /proc/vmware/config which you will find in the service console command line and then you will see the following directories

BufferCache
Cpu
Disk
FileSystem
Irq
LVM
Mem
Migrate
Misc
Net
NFS
Numa
Scsi
User
VMFS3

From these directories and the files within, you can work out the paths to be supplied to the esxcfg-advcfg command as parameters. Alternatively, you could also use the command

esxcfg-info –o

to list the advanced options.

We often see this tool used to make configuration changes relating to storage. For example, below, you can see we are checking to see if we are creating virtual disks in "eager zero" format by default, whether we will discover non-contiguous numbered LUNs, the maximum LUN number addressed,the SCSI conflict retry count and finally the logical volume manager (LVM) setting for resignaturing VMFS volumes.

[root@esx1host vmware]# esxcfg-advcfg -g /VMFS3/ZeroedThickVirtualDisks
Value of ZeroedThickVirtualDisks is 1

[root@esx1host vmware]# esxcfg-advcfg –g /Disk/SupportSparseLUN
Value of SupportSparseLUN is 1

[root@esx1host vmware]# esxcfg-advcfg –g /Disk/MaxLUN
Value of MaxLUN is 255

[root@esx1host vmware]# esxcfg-advcfg –g /Scsi/ConflictRetries
Value of ConflictRetries is

[root@esx1host vmware]# esxcfg-advcfg –g /LVM/EnableResignature
Value of EnableResignature is

In this last example, we are again setting a parameter related to storage. This parameter limits the number of outstanding disk request for each VM. This is intended to equalise the disk access between virtual machines.

[root@esx1host vmware]# esxcfg-advcfg -s 16 /Disk/SchedNumReqOutstanding

When using the esxcfg-advcfg command, remember case sensitivity!

Usage: esxcfg-advcfg <options> [<adv cfg Path>]
 -g|--get             Get the value of the config option
 -s|--set <value>     Set the value of the config option
 -d|--default         Reset Config option to default
 -q|--quiet           Suppress output
 -k|--set-kernel      Set a VMkernel load time option value.
 -j|--get-kernel      Get a VMkernel load time option value.
 -h|--help            Show this message.
 -r|--restore         Restore all advanced options from the configuration file. (FOR INTERNAL USE ONLY).

We use the esxcfg-firewall command to view and configure the firewall rules. The most popular switch will be the -q switch to query the firewall for its current settings.

[root@esxhost1 root]# esxcfg-firewall -q

<output>

The -s switch will allow you to enable or disable network services that may traverse the firewall successfully. The list of known services are shown below - very case sensitive!....

nfsClient
ftpServer
ntpClient
dellom
nisClient
vncServer
tmpLicenseClient
swISCSIClient
CIMHttpsServer
sshClient
snmpd
tmpAAMClient
vpxHeartbeats
smbClient
hpim
tmpHostVmdbServer
tmpHostdSOAPServer
ftpClient
sshServer
ibmdirector
CIMHttpServer
telnetClient

The -l switch loads the firewall and enables the IP tables.

The -u switch unloads the firewall and disables the IP tables.

We use the -e switch to enable a particular known service, so if we wanted to enable ssh outbound connections from the service console we would simply enter

[root@esxhost1 root]# esxcfg-firewall -e sshClient

We use the -d switch to disable a service. In the following example, we prevent outbound connections

[root@esxhost1 root]# esxcfg-firewall -d smbClient

If we need to open a TCP or UDP port that is not described by a defined friendly name like "sshClient", then we can explicitly open that port with the -o switch. The service console firewall is bidirectional and so when opening a port you must also specify direction of incoming or outgoing. Equally, we can close an explicit port with the -c switch.

[root@esxhost1 root]# esxcfg-firewall -o port,protocol,direction,name

In the following example, we are opening a unique port which we are calling "customapp"

[root@esxhost1 root]# esxcfg-firewall -o 12345,tcp,out,custom-app

The service names such as sshClient and smbClient are defined in the file /etc/vmware/firewall/services.xml .

[root@esx1host root]# esxcfg-module -l

Module        Type      Enabled Loaded
vmkapimod     vmkapimod true    true
vmklinux      linux     true    true
cciss.o       scsi      true    false
tg3.o         nic       true    false
qla2300_7xx.o fc        true    false

This command is often used when we want to modify a VMkernel module behaviour, for example, if we wanted to change the queue depth of our fibre-channel host bus adapter. In the following example, we are setting the queue depth for our QLogic HBA to 64; up from it's default value of 32.

[root@esx1host root]# esxcfg-module -s ql2xmaxdepth64 qla2300_707_vmw

To do the same with an Emulex HBA, we would use something like

[root@esx1host root]# esxcfg-module -s "lpfc0_lun_queue_depth=64" lpfcdd_7xx

In this example the esxcfg-rescan command is being used to rescan the VMkernel iSCSI software initiator vmhba.

[root@esx1host]# esxcfg-rescan vmhba32

esxcfg-upgrade -h --help
-g --convert-grub
-f --convert-fstab
-r --upgrade-pre-vmkernel
-o --upgrade-post-vmkernel

The -g option may only be used with the -r option.
 

[root@esx1host root]# esxcfg-vswitch -l

If you are having problems with your ESX server after an in-place upgrade, this tool is invaluable in resolving the problems with service console networking. The output of this command is initially a little intimidating. It is best to keep in mind the network topology:

Service Console IP Interface (vswif0) ---- connected to ----> Service Console Port on vSwitch ----- up-linked to ----> vmnic

Where a vmnic is a physical Ethernet adapter.

In following screenshot taken from the VI Client, we can see this ESX host has 2 connections to vSwitch0, the service console connection a VMkernel port connection.

If we wish to view the same information at the service console command line, we would use the esxcfg-vswitch command with the "-l" switch to list the defined virtual switches.

[root@esx1host root]# esxcfg-vswitch -l

Switch Name    Num Ports   Used Ports  Configured Ports  Uplinks
vSwitch0       32          4           32                vmnic0

  PortGroup Name      Internal ID    VLAN ID  Used Ports  Uplinks
  Service Console     portgroup0     0        1           vmnic0
  NFS access          portgroup1     0        1           vmnic0

If we wanted to add another virtual Ethernet switch, we would use esxcfg-vswitch command with the "-a" switch. Note that the -a is specified in lowercase. Take care to ensure you have specified lowercase because uppercase "A" performs a different function with this command. So, lets add a new virtual switch to our ESX host called vSwitch1 and then list the switches to check our command has worked ok.

[root@esx1host root]# esxcfg-vswitch -a vSwitch1
[root@esx1host root]# esxcfg-vswitch -l

Switch Name    Num Ports   Used Ports  Configured Ports  Uplinks
vSwitch0       32          4           32                vmnic0

  PortGroup Name      Internal ID    VLAN ID  Used Ports  Uplinks
  Service Console     portgroup0     0        1           vmnic0
  NFS access          portgroup1     0        1           vmnic0

Switch Name    Num Ports   Used Ports  Configured Ports  Uplinks
vSwitch1       64          0           64

  PortGroup Name      Internal ID    VLAN ID  Used Ports  Uplinks

Notice that the number of ports on the virtual switch is 64 on the newly created switch. The original virtual switch has only 32. This difference arises between creating the switch in the VI Client or the command line. Notice also that the used port count doesn't immediately make sense. Each VM consumes a port, each vmnic consumes a port and the uplink itself consumes a port. Anyway, if you are like me and you can never remember which case of the letter "a" to use when adding a virtual switch, then use the esxcfg-vswitch command with the --add switch when creating a new switch like this:

esxcfg-vswitch --add vSwitch2

which I think is a little clearer to understand.

Now if we want to add a portgroup to the new virtual switch we have created, we can use the esxcfg-vswitch -A command. It does not matter whether you are creating a service console port, a VM port group or a VMkernel port when creating a port group; the way we create the connection to the virtual switch always starts out the same in the command line. Only after creating the port group do we then specify if it is to be anything other than a VM port group. In the following commands, we add a new portgroup called "Production" on the virtual switch vSwitch1.

[root@esx1host root]# esxcfg-vswitch -A "Production" vSwitch1
[root@esx1host root]# esxcfg-vswitch -l

Switch Name    Num Ports   Used Ports  Configured Ports  Uplinks
vSwitch0       32          4           32                vmnic0

  PortGroup Name      Internal ID    VLAN ID  Used Ports  Uplinks
  Service Console     portgroup0     0        1           vmnic0
  NFS access          portgroup1     0        1           vmnic0

Switch Name    Num Ports   Used Ports  Configured Ports  Uplinks
vSwitch1       64          0           64

  PortGroup Name      Internal ID    VLAN ID  Used Ports  Uplinks
  Production          portgroup2     0        0

Alternatively you could use the following command to add a port group to a virtual switch.

[root@esx1host root]# esxcfg-vswitch --add-pg="Production" vSwitch1

This alternative switch of using --ad-pg I think is clearer for understanding what the command is doing. The --add-pg option can clearly be seen to add a portgroup to a virtual switch, and again is simpler to understand than just “-A”. The portgroup name in our example is called “Production”, but it can be what you want. We recommend adoption of a standard across all your virtual infrastructure. I have seen some clients align their portgroup names with the IP subnets, so you could have a portgroup called something like “192.168.1.0 subnet”.

Although we have now created a new virtual switch and have created a VM port group on it, the virtual switch itself does not have any uplinks. Remember that when we bind a physical network adapter to a virtual switch we are uplinking a vmnic to the switch and the switch then "owns" that adapter, i.e. it is not available to be used by any other virtual switches. We perform the uplink by using the esxcfg-vswitch command with the -L switch for link.

[root@esx1host root]# esxcfg-vswitch -L vmnic1 vSwitch1

So in one simple command we have linked the physical network adapter vmnic1 to our new virtual Ethernet switch vSwitch1. If we then realised we had used the wrong physical adapter, we can just as easily unlink with -U. In the next example, we swap the uplinked vmnic1 for an alternative adapter vmnic2

[root@esx1host root]# esxcfg-vswitch -U vmnic1 vSwitch1
[root@esx1host root]# esxcfg-vswitch -L vmnic2 vSwitch1

This changing of vmnic bound to a virtual switch is often required post-installation, as we may select the wrong physical adapter to use for the service console during the install and need to correct our configuration before we can connect to our host with VI client!

As of ESX 3.5, VMware added Cisco Discovery Protocol (CDP) support for virtual switches. We can view CDP information of the current neighbour of the physical NIC. In the VI Client, we can see this by clicking on the icon to the right side of the vmnic in the network view of the ESX host.

To display the CDP configuration setting for a virtual switch, we use the lowercase b switch, where we will find which of the four CDP modes it is in: disable, listen, advertise or both.

[root@esx1host root]# esxcfg-vswitch -b vSwitch0
listen

We can change the CDP mode with the -B (uppercase) option. Here we are changing virtual switch called vSwitch0 to support both advertise and listen.

[root@esx1host root]# esxcfg-vswitch -B both vSwitch0
[root@esx1host root]# esxcfg-vswitch -b vSwitch0
both
 

[root@esx1host root]# esxcfg-auth --enablead --addomain=taupoconsulting.com --adddc=dc1.taupoconsulting.com

You can also use this tool to set a password policy for service console user accounts.

[root@esx1host root]# esxcfg-auth --maxpassdays=90 --minpassdays=30 --passwarnage=75

In the above example, your service console user account password would expire after 90 days, you would get a warning message after 75 and once changed, you would have to keep that password for a minimum period of 30 days.

In this first example, we will run the command with no switches and pipe the result into a file esxinfo.txt.

[root@esx1host root]# esxcfg-info >esxinfo.txt

If you know the area you are looking at, e.g. storage, then we can launch the tool with the appropriate switch. Here are the six switch options:

w   hardware
r   resource
s   storage
n   network
y   system
o   advanced options

If we combine the filtering of the output using the above switches along with a grep filter we can really zoom in on the area we are interested in. An excellent VMware communities post gives an example of using the storage switch whilst looking for Pending reservations on LUNs. We are piping the result of the storage output of esxcfg-info into the input for grep.

[root@esx1host]# esxcfg-info -s | grep Pending

Check out the post at http://communities.vmware.com/thread/156778?tstart=0
 

[root@esx1host tools-isoimages]# esxcfg-mpath -l

Disk vmhba0:0:0 /dev/cciss/c0d0 (69459MB) has 1 paths and policy of Fixed
Local 2:1.0 vmhba0:0:0 On active preferred

Disk vmhba1:0:0 (0MB) has 1 paths and policy of Most Recently Used
FC 10:1.0 210000e08b846a72<->5006016930221397 vmhba1:0:0 On active preferred

Disk vmhba1:0:6 /dev/sda (9216MB) has 1 paths and policy of Most Recently Used
FC 10:1.0 210000e08b846a72<->5006016930221397 vmhba1:0:6 On active preferred

Disk vmhba1:0:21 /dev/sdb (10240MB) has 1 paths and policy of Most Recently Used
FC 10:1.0 210000e08b846a72<->5006016930221397 vmhba1:0:21 On active preferred

[root@esx1host root]# esxcfg-vmhbadevs
vmhba0:0:0    /dev/sda
vmhba0:0:1    /dev/sdb
vmhba0:0:2    /dev/sdc
vmhba0:0:3    /dev/sdd
vmhba2:0:0    /dev/sde
vmhba2:1:0    /dev/sdf

If we use this command with the –m switch, then we only list the LUNs which contain VMFS partitions. Alongside the Linux device name, a long unique hexadecimal value is listed. This is the VMFS volume signature assigned by the new logical volume manager (LVM).

[root@esx1host root]# esxcfg-vmhbadevs -m
vmhba0:0:0:1 /dev/sda1 45407607-fbc43ced-94cb-00145e231ce3
vmhba0:0:2:1 /dev/sdc1 455b08a8-8af7fee3-daa9-00145e231e35
vmhba2:0:0:3 /dev/sde3 4559c75f-831d8f3e-bc81-00145e231e35

You can view these volumes in the directory /vmfs/volumes/

[root@esx1host root]# esxcfg-boot -q boot
272 2:;7:;10:; UUID=847199e4-d3c7-11da-8ef8-930e3d734c03 /vmlinuz-2.4.21-37.0.2.ELvmnix /initrd-2.4.21-37.0.2.ELvmnix.img

[root@esx1host root]# esxcfg-boot -q vmkmod
vmkapimod vmkapimod
vmklinux linux
cciss.o scsi
tg3.o nic
qla2300_7xx.o fc

This is also used if you making modifications to VMkernel device drivers defaults. For example, if you were modifying the queue depth for a fibre HBA, you would likely be using esxcfg-module. Then to rebuild the boot image you would enter

[root@esx1host root]# esxcfg-boot -m

After which, you would do a reboot the host to test that the update to the boot image had worked.

The esxcfg-nas command is used to list, mount and dismount NFS exports for the VMkernel. In the first example we list the NFS datastores which the VMkernel has mounted.

[root@esx1host root]# esxcfg-nas -l
NFS01 is /NFS from 100.100.100.253 mounted

In the next example, we add a new VMkernel mount to a remote NFS server. This time we are connecting to the NFS server at IP address 100.100.100.253 and the name of the exported directory is “/Test”. We are labelled this NFS mount “NFS02”.

[root@esx1host etc]# esxcfg-nas -a -o 100.100.100.253 -s /Test NFS02
Connecting to NAS volume: NFS02
NFS02 created and connected.

Remember that to create a connection to an NFS datastore, the VMkernel needs to have an IP address, as it is the NFS client. We give the VMkernel an IP address by creating a VMkernel port on a virtual Ethernet switch. We can do this at the command line using the command esxcfg-vmknic

The command line options for esxcfg-nas are:

esxcfg-nas <options> [<label>]
 -a|--add               Add a new NAS filesystem to /vmfs volumes. Requires --host and --share options.
 -o|--host <host>       Set the host name or ip address for a NAS mount.
 -s|--share <share>     Set the name of the NAS share on the remote system.
 -d|--delete            Unmount and delete a filesystem.
 -l|--list              List the currently mounted NAS file systems.
 -r|--restore           Restore all NAS mounts from the configuration file. (FOR INTERNAL USE ONLY).
 -h|--help              Show this message.

[root@esx1host etc]# esxcfg-route
VMkernel default gateway is 100.100.100.254

[root@esx1host etc]# esxcfg-route 100.100.100.1
VMkernel default gateway set to 100.100.100.1

If you need to create a VMkernel port at the command line, then you need to create a port group first and then enable it as a VMkernel port. This tool does not allow you to enable the VMkernel port for VMotion, you must either use vimsh or the VI client for that.

[root@esx1host root]# esxcfg-vswitch -A VMotion vSwitch0
[root@esx1host root]# esxcfg-vmknic -a -i 100.100.100.121 -n 255.255.255.0 VMotion

The above commands would result in an additional connection to the virtual Ethernet switch, specifically a VMkernel port. The esxcfg-vmknic command has assigned the VMkernel an IP address & the portgroup called VMotion is now explicitly VMkernel port. The following screenshot displays the new VMkernel port connection on vSwitch0.

In the following example, we list the VMkernel ports, then use esxcfg-vmknic to delete one of them and then list them again.

[root@esx1host etc]# esxcfg-vmknic -l

Port Group          IP Address      Netmask         Broadcast       MAC Address       MTU     Enabled
NFS access          100.100.100.21  255.255.255.0   100.100.100.255 00:50:56:62:ca:f6 1514    true
VMotion             100.100.100.121 255.255.255.0   100.100.100.255 00:50:56:6d:7c:7d 1514    true

[root@esx1host etc]# esxcfg-vmknic -d VMotion
[root@esx1host etc]# esxcfg-vmknic -l

Port Group          IP Address      Netmask         Broadcast       MAC Address       MTU     Enabled
NFS access          100.100.100.21  255.255.255.0   100.100.100.255 00:50:56:62:ca:f6 1514    true

The command line options are:

esxcfg-vmknic <options> [[<portgroup>]]
-a|--add                  Add a VMkernel NIC to the system, requires IP parameters and portgroup name.
-d|--del                  Delete VMkernel NIC on given portgroup.
-e|--enable               Enable the given NIC if disabled.
-D|--disable              Disable the given NIC if enabled.
-l|--list                 List VMkernel NICs.
-i|--ip <X.X.X.X>         The IP address for this VMkernel NIC. Setting an IP address requires that the
                          --netmask option be given in same command.
-n|--netmask <X.X.X.X>    The IP netmask for this VMkernel NIC. Setting the IP netmask requires that the --ip
                          option be given in the same command.
-r|--restore              Restore VMkernel TCP/IP interfaces from Configuration file (FOR INTERNAL USE ONLY).
-h|--help Show this message.

So far, we have only used this utility to interrogate ESX hosts to determine where the dump partition has been created. Here is an example of viewing the dump partition.

# esxcfg-dumppart -l

VM Kernel Name      Console Name        Is Active   Is Configured
vmhba0:0:0:7        /dev/cciss/c0d0p7   yes         yes

Remember that the dump partition does not show up when you run the vdf utility. However it is visible if you run fdisk. In the following example, we are running fdisk to view the partitions. We can see the dump partition as c0d0p7, i.e. partition #7. Notice the Id of that partition is "fc", the custom partition type for VMkernel dump partitions.

# fdisk /dev/cciss/c0d0

Disk /dev/cciss/c0d0: 36.3 GB, 36385505280 bytes
64 heads, 32 sectors/track, 34699 cylinders
Units = cylinders of 2048 * 512 = 1048576 bytes

           Device Boot    Start       End    Blocks   Id  System
/dev/cciss/c0d0p1   *         1       100    102384   83  Linux
/dev/cciss/c0d0p2           101      5100   5120000   83  Linux
/dev/cciss/c0d0p3          5101      7100   2048000   83  Linux
/dev/cciss/c0d0p4          7101     34699  28261376    f  Win95 Ext'd (LBA)
/dev/cciss/c0d0p5          7101      7644    557040   82  Linux swap
/dev/cciss/c0d0p6          7645     34599  27601904   fb  Unknown
/dev/cciss/c0d0p7         34600     34699    102384   fc  Unknown

The command line options are:

esxcfg-dumppart <options> [<partition>]
-l|--list            List the partitions available for Dump Partitions. WARNING: This will scan all LUNs on the system.
-t|--get-active      Get the active Dump Partition for this system, returns the internal name of the partition
                     vmhbaX:X:X:X) or 'none'.
-c|--get-config      Get the configured Dump Partition for this system, returns the internal name of the partition
                     vmhbaX:X:X:X) or 'none'.
-s|--set             Set the Dump Partition for this system and activate it, either vmhbaX:X:X:X or 'none' to
                     deactivate the active dump partition.
-f|--find            Find usable Dump partitions and list in order of preference.
-S|--smart-activate  Activate the configured dump partition or find the first appropriate partition and use it(same
                     order as -f).
-a|--activate        Activate the configured dump partition.
-d|--deactivate      Deactivate the active dump partition.
-h|--help            Show this message.
 

When you are working in the service console while the VMkernel is loaded, the service console's network interface is not called eth0, but is called vswif0 instead. This is because the service console network interface is provided via a service console portgroup on a virtual Ethernet switch. If you restart your ESX server without the VMkernel, then standard Linux drivers and network card management is used. Therefore the network interface used in troubleshooting mode is called eth0 - just like any other regular Linux box. This tool is called by starting troubleshooting mode to replicate the IP parameters assigned to vswif0 to eth0.

Should you want to investigate this command, the options are:

esxcfg-linuxnet --setup
--remove
-h --help

The --setup option cannot be combined with the --remove option.

In the following example, we run the list option to view all physical NICs and their properties.

[root@esx1host etc]# esxcfg-nics -l

Name   PCI      Driver  Link Speed    Duplex Description
vmnic2 01:01.00 tg3     Up   1000Mbps Full Broadcom Corporation NetXtreme BCM5703 Gigabit Ethernet
vmnic0 01:02.00 tg3     Up   100Mbps  Full Broadcom Corporation NC7781 Gigabit Server Adapter (PCI-X, 10,100,1000-T)
vmnic1 04:02.00 tg3     Up   1000Mbps Full Broadcom Corporation NC7781 Gigabit Server Adapter (PCI-X, 10,100,1000-T)

This command has the following optional parameters:

esxcfg-nics <options> [nic]
-s|--speed <speed> Set the speed of this NIC to one of 10/100/1000/10000. Requires a NIC parameter.
-d|--duplex <duplex> Set the duplex of this NIC to one of 'full' or 'half'. Requires a NIC parameter.
-a|--auto Set speed and duplexity automatically. Requires a NIC parameter.
-l|--list Print the list of NICs and their settings.
-r|--restore Restore the nics configured speed/duplex settings (INTERNAL ONLY)
-h|--help Display this message.
 

In VI-3, one of the supported iSCSI hardware HBAs is the QLogic 4052. More information about this particular family of adapters can be found at http://support.qlogic.com/support/product_resources.asp?id=964

In software iSCSI initiator, the wrapping of SCSI commands in IP is performed by the VMkernel and a regular physical network card is used to communicate with the iSCSI target. The software iSCSI configuration is exposed in the VI Client as a host bus adapter called vmhba40 in ESX 3.0.x and is called vmhba32 in ESX 3.5. We can use this command line tool esxcfg-swiscsi to configure the software iSCSI initiator. The software iSCSI initiator in the VMkernel has a dependency upon the service console, therefore both the service console and VMkernel must have an IP route to the iSCSI target. The esxcfg-swiscsi command is not used in isolation, we use it in a sequence of commands to fully configure iSCSI from the service console command line.

1. Add a VMkernel port to a vSwitch that has an uplink and route to iSCSI target
2. Ensure service console IP interface has a route to the same iSCSI target
3. Using either the VI Client security profile or the esxcfg-firewall, open a port in the service console firewall for iSCSI (TCP:3260)
4. In the command line, enable iSCSI with the command esxcfg-swiscsi -e
5. Enable a discovery address with the command vmkiscsi-tool -D -a 10.0.0.99 vmhba32
6. List the targets that were discovered with vmkiscsi-tool -T -l vmhba32
7. Perform a rescan with esxcfg-rescan vmhba32
8. List the iSCSI LUNs with vmkiscsi-tool -L -l vmhba32

If you want to ensure the VI client reflects the changes made at command line, it is best to restart the vmware management service with the command service mgmt-vmware restart

The full list of command line options for this command are:

-e, --enable Enable sw iscsi
-d, --disable Disable sw iscsi
-q, --query Check if sw iscsi is on/off
-s, --scan Scan for disk available through sw iscsi interface
-k, --kill Try to forcibly remove iscsi sw stack
-r, --restore Restore sw iscsi configuration from file (FOR INTERNAL USE ONLY)
-h, --help Show this message

During installation of ESX server, your service console Ethernet connection should  have been created. However, maybe a mistake was made, or we want to add another service console port for redundancy.

In VI Client we can view the network configuration of our ESX host. Here is an example of a typical network configuration.

If we use the esxcfg-vswif tool, we are examining, creating or modifying a service console port. So in the first example here, we are simply listing what ports have been created.

# esxcfg-vswif -l

Name     Port Group          IP Address       Netmask          Broadcast        Enabled   DHCP
vswif0   Service Console     192.168.31.31    255.255.255.0    192.168.31.255   true      false

So the output is showing the same as the graphical output in VI client.

If we wanted to add a 2nd service console port, we could use this command. However, all this command will do is turn a regular portgroup into a service console port and bind an IP address to Linux. So in the following command line example, we create a portgroup first, and then we turn it into a service console port with esxcfg-vswif.

# esxcfg-vswitch --add-pg="Service Console Backup" vSwitch1
# esxcfg-vswif -a -i 10.10.1.31 -n 255.255.0.0 -p "Service Console Backup" vswif1

[2007-11-21 11:29:18 'Vnic' warning] Generated New MAC address, 00:50:56:4d:da:97 for vswif1
Nothing to flush.

So now if we run esxcfg-vswif to list the service console ports, we will be able to see the original service console port as well as our new one we just created. We've shown you the graphical representation as well from the VI client so you can compare.

# esxcfg-vswif -l

Name     Port Group              IP Address       Netmask          Broadcast        Enabled   DHCP
vswif0   Service Console         192.168.31.31    255.255.255.0    192.168.31.255   true      false
vswif1   Service Console Backup  10.10.1.31       255.255.0.0      10.10.255.255    true      false

A new function was added to esxcfg-vswitch when ESX 3.5 was released at the end of 2007. This version of ESX server was the first to support Ethernet Jumbo Frames. This is where the MTU size is increased beyond the default 1500 bytes. In the following example, we are changing the maximum MTU for vSwitch1.

# esxcfg-vswitch -m 9000 vSwitch1

/etc/vmware/hwconfig
/etc/vmware/devnames.conf
/etc/vmware/vmkmodule.conf
/etc/vmware/netmap.conf
/etc/vmware/vmkconfig

This file should not be copied from one ESX host to another in order to duplicate configuration, it is unique to the host. The file groups similar settings by using a notation similar to directories and subdirectories; for example, here is a section of esx.conf

<output>

There will be a number of lines to this file, but the one you are likely to be interested in will start "hosts:" as shown:

hosts: files dns

In the above example, the name service will use the /etc/hosts file, and then the DNS name server specified in the /etc/resolv.conf file.

We can restart the host management agent with the command

service mgmt-vmware restart

  <service id='0000'>
    <id>sshServer</id>
    <rule>
      <direction>inbound</direction>
      <protocol>tcp</protocol>
      <port type='dst'>22</port>
      <flags>-m state --state NEW</flags>
    </rule>
  </service>

You could modify this XML file to include your own definitions but this is not recommended by VMware. The VMware management agent (hostd) will load everything in this file, whether it is valid or not. Also, we have not tested if such a change would persist through a patching/upgrade, but we suspect not. Duncan Epping over at Yellow Bricks has done some great testing and documentation in this space and at the following link demonstrates how to add your own custom.xml file to the /etc/vmware/firewall directory (using same format as services.xml) to provide custom port definitions. You can read all about it at http://www.yellow-bricks.com/2007/12/31/howto-adding-a-firewall-service-on-esx/. Just make sure you use ids in the file that are different than the ones in services.xml.

service vmware-vpxa restart

[root@esx1host vmware]# cat vpxa.cfg
<config>
  <log>
    <outputToConsole>false</outputToConsole>
  </log>
 <nfc>
   <loglevel>error</loglevel>
 </nfc>
 <vmacore>
   <ssl>
     <doVersionCheck>false</doVersionCheck>
   </ssl>
   <threadpool>
     <TaskMax>10</TaskMax>
   </threadpool>
   </vmacore>
   <vpxa>
     <datastorePrincipal>root</datastorePrincipal>
     <hostIp>100.100.100.11</hostIp>
     <memoryCheckerTimeInSecs>30</memoryCheckerTimeInSecs>
     <serverIp>100.100.100.172</serverIp>
     <serverPort>902</serverPort>
   </vpxa>
   <workingDir>/var/log/vmware/vpx</workingDir>

Notice the <loglevel> tag. If you are trying to troubleshoot an issue, then increasing the logging level is a good idea. We have used the level "verbose", there could be a higher debug level of logging, but we've not tested that. We have also found the loglevel trivia, info, warning and error.
 

There is a great switch with the command -X which can be used to extend the size of your virtual disk; e.g. if you had a 10GB virtual disk and wanted to expand it to 20GB, you could use this command. The VM would need to be powered off for this to work.

vmkfstools -X 20GB /vmfs/volumes/storage1/vm.vmdk

Note that the -X switch specifies the NEW SIZE of the virtual disk and NOT how much you are extending it by.

If you have used the -X switch before in an older version of ESX server (earlier than 3.0) it was possible to specify a small disk size; thereby making the virtual disk smaller. This was dangerous but useful if your partition within the disk did not consume 100% of the disk size. However, this is not possible with vmkfstools command found in ESX Server version 3.x.

From ESX 3.5, the size of a virtual disk can now be increased in the VI Client! VMware are implementing more and more in the user interface, less time needed in the service console command line...

Previously, the main use of vmkfstools command was to import or export virtual disks. This would be required if you were deploying templates by hand instead of using VirtualCenter. It was also the primary method for moving VMs between the ESX server product and the hosted VMware products such as VMware Workstation or Server. The reason we say "previously" is that moving VMs between servers or between VMware products has become much simpler and cleaner by using the VMware Converter utility. This tool is task oriented and treats the VM as a whole object, not just the virtual disk files as vmkfstools.

If you do want to import virtual hard disks in 2GB sparse format into monolithic format by hand, then we can use vmkfstools command with the -i switch.

vmkfstools -i /importfiles/vm.vmdk /vmfs/volumes/storage1/vm/vm.vmdk

Notice that the import option requires two parameters, source and destination. This would not create a VM, but would create the monolithic virtual disk for a VM. You could then create a custom VM in the VI Client and select the option to "use an existing disk".

If you want to export a virtual disk you no longer use the -d switch, but just use -i and specify the virtual disk type at the destination of the import. So if you were exporting a virtual disk from VMFS to

vmkfstools -i /vmfs/volumes/storage1/vm/vm.vmdk -d 2gbsparse /exportvm/vm.vmdk

# vmware-cmd -s register /vmfs/volumes/SharedVMs/vm1/vm1.vmx
# vmware-cmd /vmfs/volumes/SharedVMs/vm1/vm1.vmx start

If you have a VM that you can't tell if it is powered on or off, you can use the getstate option

# vmware-cmd /vmfs/volumes/SharedVMs/vm1/vm1.vmx getstate
vm1 is powered on

If you need to force the VM to power off, the stop hard function will normally do the trick. This is not very graceful, but can save you time if things are not responding.

# vmware-cmd /vmfs/volumes/SharedVMs/vm1/vm1.vmx stop hard

If there is limited space in your VMFS volumes, then you will likely want to know if any of your VMs are running in snapshot (where the disk writes are going into a disk delta and not the regular parent virtual disk). It is a nice idea to have a short script to enumerate the VMs on your host and loop through them to check each of them to see if they have a snapshot. The vmware-cmd command again helps us out with this.

A useful function of this tool is to list running VMs using the -x switch.

<output>

[root@esx1 root]#

Watch out for the creation of empty subdirectories of the name "vm-support.<pid-of-process>" in the directory where you run this tool with the -x switch. It is safe to delete these directories. You can't run this command if your current directory is /proc.

A less well-known option of vm-support is the ability to capture host performance data which can be replayed later using esxtop. To invoke the performance capture, we need to specify how frequently a performance "snapshot" is taken and over what period of time. For example, if we wished to capture host performance every 30 seconds for 10 minutes, then we would invoke vm-support with the following options

[root@esx1 root]# vm-support -S -i 30 -d 600

The performance snapshots are archived automatically into a tgz file (a tgz file just like a WinZIP (R) archive). The tgz archive file name produced is unique to each time it's run, as the name includes date, time and process id of vm-support. Before we can actually replay the snapshot performance data in esxtop, we need to extract the tgz archive. The tar command is used to "unzip" tgz archive files.

[root@esx1 root]# tar -zxvf archive.tgz

To replay the data in esxtop, use the "-R" switch to specify replay mode and supply the path to the performance capture file produced by vm-support.

The power of the esxupdate command is realised when you use it with a patch repository. A patch repository can be exposed to a host via HTTP, FTP or NFS.

esxupdate -d ftp://taupopatchserver/esx35/0710-03 scan

- Bundle Name -      AppFlags             --- Summary ---              iFlags
ESX350-200710049-BG  -------v Bugs fixed in some vmkernel.             rm-  
ESX350-200710050-SG  i------v Security bugs fixed in vmkernel module.. rm-  
ESX350-200710052-BG  i------v Several bugs fixed in vmx module...      -m-  
ESX350-200710053-BG  -------- Provided new PBM for SUSE 11 U2.         ---  
ESX350-200710054-BG  -------v COS fix for Ooops.                       rm-  
ESX350-200710055-BG  -------- More fixes in scsi drivers.              r--  
ESX350-200710058-RG  -------v This is a roll-up bundle.                rm-  
ESX350-200710059-RG  -------v This is a roll-up security bundle.       rm-  

If you choose to use the new VirtualCenter Server 2.5 feature called VMware Update Manager (VUM), then when you perform host scans and remediation, you are in fact just remotely invoking this utility, it's just you don't see it!

You can use the --explain switch when scanning to provide a greater level of detail to your host patch scan operation. If for example, the AppFlags for a patch indicated "c" for conflict, you would probably want to know what exactly the patch was in conflict with.

If you are using ESX versions prior to 3.5 then use

vimsh -n -e "hostsvc/vmotion/vnic_set portgroupname

However, if you are using ESX version 3.5 then we need to use a slightly different syntax for specifying the portgroup to enable. We now need to specify using a vmkx notation. Trouble is, we don't know which portgroup corresponds to which vmkx number. So to first identify the mapping of portgroup name to vmk number, we enter the command

vimsh

and then enter hostsvc/vmotion/netconfig_get and we'll get a whole pile of output, but buried in there will be the device names in vmkx format that we can then use to enable VMotion on that portgroup with the following:

vimsh -n -e "hostsvc/vmotion/vnic_set vmk0

Using the vimsh command for enabling VMotion is just 1% of the functionality of this tool. It's not for the faint hearted and there really is no better source of information about it than the PDF documents that the xtravirt guys have written. Thanks also to Mike Laverick of RTFM Education (www.rtfm-ed.co.uk) for documenting the changes in vimsh in version 3.5.

If you are unfamiliar with RPMs in Linux, think of them like MSI packages in Windows.

The rpm command can be used to list and to install RPM-based applications. In the following example, we are using the command switch (-qa) to list the rpms installed in the service console.

# rpm -qa
libgcc-3.2.3-53
setup-2.5.27-1
basesystem-8.0-2
tzdata-2005m-1.EL3
glibc-2.3.2-95.37
bzip2-libs-1.0.2-11.EL3.4
etc!.....

If we are only interested in the VMware rpms, then we can just pipe the output of rpm -qa command into the grep search tool.

rpm -qa |grep VMware

which should yield an output something like

VMware-webCenter-esx-2.0.1-32041
VMware-esx-apps-3.0.1-32039
VMware-esx-iscsi-3.0.1-32039
VMware-esx-uwlibs-3.0.1-32039
VMware-esx-vmkernel-3.0.1-32039
VMware-esx-drivers-block-DAC960-2.4.11-32039
VMware-esx-drivers-net-bcm5700-7.3.5-32039
VMware-esx-drivers-net-e100-2.3.40-32039
VMware-esx-drivers-net-pcnet32-1.30c-32039
VMware-esx-drivers-net-tg3-3.43b.1vmw-32039
VMware-esx-drivers-scsi-adp94xx-0.0.5-32039
VMware-esx-drivers-scsi-aic7xxx-6.3.9-32039
VMware-esx-drivers-scsi-lpfcdd-v732-7.3.2.1vmw-32039
VMware-esx-drivers-scsi-megaraid_sas-0.0.2-32039
VMware-esx-drivers-scsi-qla2200-v7.07-7.7.4.1vmw-32039
VMware-esx-drivers-scsi-qla4010-3.24-32039
VMware-esx-drivers-scsi-vmkiscsi-3.4.2-32039
VMware-hostd-esx-3.0.1-32039
VMware-esx-lnxcfg-3.0.1-32039
VMware-esx-perftools-3.0.1-32039
VMware-esx-docs-3.0.1-32039
VMware-esx-tools-3.0.1-32039
VMware-esx-vmkctl-3.0.1-32039
VMware-esx-drivers-block-cciss-2.4.54-32039
VMware-esx-drivers-net-3c90x-1.0.2-32039
VMware-esx-drivers-net-bnx2-1.3.22-32039
VMware-esx-drivers-net-e1000-7.0.33.2vmw-32039
VMware-esx-drivers-net-s2io-1.7.6-32039
VMware-esx-drivers-scsi-aacraid_esx30-1.1.5.1vmw-32039
VMware-esx-drivers-scsi-aic79xx-6.3.9-32039
VMware-esx-drivers-scsi-ips-7.10.17.1vmw-32039
VMware-esx-drivers-scsi-megaraid2-2.10.7-32039
VMware-esx-drivers-scsi-mptscsi_2xx-2.6.34.1vmw-32039
VMware-esx-drivers-scsi-qla2300-v7.07-7.7.4.1vmw-32039
VMware-esx-drivers-scsi-qla4022-3.24-32039
VMware-esx-vmx-3.0.1-32039
VMware-esx-srvrmgmt-3.0.1-32039
VMware-esx-backuptools-3.0.1-32039
VMware-esx-scripts-3.0.1-32039
VMware-esx-3.0.1-32039
VMware-cim-esx-3.0.1-32039
VMware-vpxa-2.0.1-32042
 

If we then want to find out more information on an individual RPM package, we can use the rpm -qi option to query a package which reports the file version, vendor, license and description.

# rpm -qi VMware-hostd-esx-3.0.1-32039

Name        : VMware-hostd-esx             Relocations: (not relocatable)
Version     : 3.0.1                             Vendor: VMware, Inc.
Release     : 32039                         Build Date: Tue 26 Sep 2006 01:30:42 AM PDT
Install Date: Tue 06 Nov 2007 03:07:02 PM PST      Build Host: pa-build43.eng.vmware.com
Group       : Applications/Emulators        Source RPM: VMware-hostd-esx-3.0.1-32039.src.rpm
Size        : 269864433                        License: commercial
Signature   : (none)
Summary     : VMware Host Agent package.
Description :

If we then want to know what files are included in the rpm package, we can use query with the list option to see the files inside. For example, to see the files

# rpm -ql VMware-hostd-esx-3.0.1-32039

/etc/vmware/hostd/config.xml
/etc/vmware/hostd/env/0.xml
/etc/vmware/hostd/env/1.xml
/etc/vmware/hostd/env/vmconfigoption-esx-2.5.0.xml
/etc/vmware/hostd/env/vmconfigoption-esx-3.0.0.xml
/etc/vmware/hostd/environments.xml
/etc/vmware/hostd/esxinfo.vha
.....
 

Once you have copied out the file you were after, you can safely delete the contents of that temp directory. In other words, we have used rpm2cpio to extract the RPM archive.

Here is an example using the RPM we've used in the previous examples.

# rpm2cpio VMware-hostd-esx-3.0.1-32039 | cpio -idmv

i = Restore archive
d = Create landing directories
m = Create previous file modification times
v = verbose

The configuration of SSH client is stored in the text file /etc/ssh/ssh_config

The configuration of the SSH server daemon is stored in the text file /etc/ssh/sshd_config. An important setting in this file is PermitRootLogin=No. This is the default setting in ESX 3.x and it is recommended that you keep the setting at "No". This way you have an audit trail and see exactly who is logging in, rather than just "root". You can quickly what the setting is by using a grep operation on the file as shown:

# grep Permit /etc/ssh/sshd_config

If you do edit the file to change this setting to Yes, then make sure you restart the daemon for the changes to take effect using the command:

# service sshd restart

It is also possible to explicitly allow or deny specific users to the SSH daemon. The headings in the ssh_config file are DenyUsers and AllowUsers.

When it used without parameters, we are specifying to switch to the user root. However, we can use the su command to switch shell to any user account that we know the password of. In the first example, we are logged in as the user kevin and we are switching to user ali.

[kevin@esx1host kevin]$ su ali
Password:
[ali@esx1host kevin]

In this second example, we are switching from being logged on as a user called sara to being logged on as root. Notice to switch to root, we don't need to specify a username.

[sara@esx1host sara]$ su -
Password:
[root@esx1host root]#

If we restrict the built-in user account root from logging in over the SSH protocol, then we are forcing remote users to authenticate as themselves and then su to run privileged commands if need be, thus leaving a decent audit trail. The downside being that those users would still know the root account password.

There is a single line in this file that needs to be uncommented to limit the use of su. The line is shown below as it appears it that file, all that is required is the removal of the # symbol at the start of the line.

#auth required /lib/security/$ISA/pam_wheel.so user_uid

The attempts to switch to the root account are logged in /var/log/messages.

Allows delegation of administration in terms of certain commands that normally only a particular user can execute (usually root). So if the user ali had been given the authority to run vmkfstools, then sudo would be used like:

[ali@esx1 ali]$ sudo vmkfstools

The vmkfstools command would then run under the security context of the root user. The superb feature of this tool is that the user ali does not need to know or supply the root password to be able to run the delegated command. Further, we keep an audit trail of when sudo was invoked in /var/log/secure.

The sudo tool uses the lookup file /etc/sudoers to determine which users can perform which commands. We do not edit this file with a regular text editor like vi or nano, instead we use the tool visudo.
 

A great benefit of using visudo over regular vi, is that it performs some basic syntax checking for us!

alistair ALL=  /bin/kill, /usr/bin/, /usr/sbin/alistair/

In the following line added to the /etc/sudoers file, we are allowing the user sara to run the esxcfg-firewall and esxcfg-vswitch command.

sara     ESX1= /usr/sbin/esxcfg-firewall, esxcfg-vswitch

You can use aliases within this file to group together users, hosts and commands.

User_Alias ESXHOSTADMINS-PROD = john, grant, julie
User_Alias ESXHOSTADMINS-TEST = peter
Host_Alias PRODESXHOSTS = esxprodsrv01, esxprodsrv02
Host_Alias TESTESXHOSTS = esxtest01, esxtest01
Cmnd_Alias SECURITYCOMMANDS =
Cmnd_Alias VMCOMMANDS =
Cmnd_Alias NETCOMMANDS = /usr/sbin/esxcfg-vswitch, /usr/sbin/esxcfg-nics, /usr/sbin/esxcfg-vmknic

Now we can combine these to create rules such as;

ESXHOSTADMINS = PRODESXHOSTS NETCOMMANDS

Although, rather than maintaining a static configuration file on each ESX host, it would be better to customize the sudoers file during host deployment and include Linux groups. For example, if we wanted to delegate a set of commands to those Linux users who belong to a Linux group, for example, wheel, then we can use the % operator to leverage those group definitions.

%wheel = PRODESXHOSTS SECURITYCOMMANDS

The best source we've found so far on detailed use and background of sudo can be found at http://aplawrence.com/Basics/sudo.html

[root@esx1host firewall]# w
 12:07:45  up 4 days,  2:16,  3 users,  load average: 0.00, 0.00, 0.00
USER     TTY      FROM              LOGIN@   IDLE   JCPU   PCPU  WHAT
root     tty1     -                Fri10am  4days  0.02s  0.02s  -bash
root     tty2     -                Fri 9am  4days  0.06s  0.06s  -bash
root     pts/0    remote7.lab.vmwa  9:29am  0.00s  0.06s  0.00s  w

[root@esx1host firewall]# who
root     tty1         Jul 25 10:30
root     tty2         Jul 25 09:56
root     pts/0        Jul 29 09:29 (remote7.lab.b2v.net)

If we want to see all the details of users we can use the -a switch to show all data. We tend to combine -a with -H (i.e. -aH) to display column headers making it easier to read and interpret.

[root@esx1host firewall]# who -aH
NAME       LINE         TIME         IDLE          PID COMMENT  EXIT
                        Jul 25 09:51               743 id=si    term=0 exit=0
           system boot  Jul 25 09:51
           run-level 3  Jul 25 09:51                   last=S
                        Jul 25 09:52              1205 id=l3    term=0 exit=0
root     + tty1         Jul 25 10:30  old         2056
root     + tty2         Jul 25 09:56  old         2057
LOGIN      tty3         Jul 25 09:52              2058 id=3
LOGIN      tty4         Jul 25 09:52              2059 id=4
LOGIN      tty5         Jul 25 09:52              2060 id=5
LOGIN      tty6         Jul 25 09:52              2061 id=6
root     + pts/0        Jul 29 09:29   .         18092 (remote7.lab.b2v.net)

In the following example, we are examining the options for the Intel network driver (e1000) with the -s (show parameters) switch and then unloading it using -u (thereby interrupting network operations on that physical interface temporarily) and then loading it again with a new option. Notice to load a VMkernel parameter, we just supply the module name to the vmkload_mod command as a parameter listing any module-specific options as further parameters.

[root@esx1host]# vmkload_mod -s e1000
Using /usr/lib/vmware/vmkmod/e1000.o
heap_initial int, description "Initial heap size allocated for the driver."
heap_max int, description "Maximum attainable heap size for the driver."
reset_wait_ms int array (min = 1, max = 32)

[root@esx1host]# vmkload_mod -u e1000
[root@esx1host firewall]# vmkload_mod e1000 RxIntDelay=32
Using /usr/lib/vmware/vmkmod/e1000.o
Module load of e1000 succeeded.

If you were experimenting with a driver setting to determine the right setting for the environment, then you may be loading and unloading a module a number of times. Once we were happy we had found the correct setting, it is likely we would want to make this change persistent, i.e. we would want it to take effect for each time the kernel module is loaded at server boot time. For that, we should use esxcfg-module command.

Minicom uses a configuration file to determine bit rates etc. This configuration file is placed in the /etc directory. We normally create the file with a meaningful name e.g. minirc.com1, so to launch the tool we enter

# ./minicom com1

The contents of the minirc.com1 file would typically be:

pr port		/dev/ttyS0
pu baudrate	19200
pu bits		8
pu parity	N
pu stopbits	1
pu rtscts	No

Much more detail on minicom can be found at http://www.cisl.ucar.edu/nets/intro/staff/siemsen/tools/minicom.html

vi filename

The first thing that throws you is that to enter text into your file, you need to press "i" for Insert mode. You can then enter your text just as any other text editor. When you are done with text entering, just press the Escape (Esc) key to come out of insert mode. If you are happy with your file, then we need to Write & Quit (wq). To enter commands in this command line editor, rather than having menus, we have a command prompt in the application. To reach the vi command prompt, simply enter ":" - the colon character which will automatically place your cursor at the bottom of the session. Here you can enter the "wq" command to write and quit the editor. That's it!

Here is a summary of the vi commands

i                  Changes to insert mode where you can edit the text
:wq               Write the file and quit the editor
:q!               Quit the editor without saving changes

SHIFT ZZ       Quit the editor and save any changes made - just a fast way of doing ":wq"
Esc key          Exits the current mode, e.g. out of insert mode back to view mode.

These commands are just extra if you have the inclination to learn!

/                     search - if you entered /failed then the cursor would move to the first instance of "failed in the text
$                     jumps to the end of the opened file
yy                   copy - it's y for yank!
dd                   delete a line (cut) if you precede this with a number e.g. 8dd, then it would delete 8 lines
p                     paste
%s/old/new/g    substitute any occurrences of the world "old" with the world "new"

There are some great web sites which document the features of vi in superb depth, one of them is the staff site at University of Washington which helped me. Their site is at http://staff.washington.edu/rells/R110/

[root@esx7 firewall]# cat /etc/ntp.conf
# Prohibit general access to this service.
restrict default ignore

# Permit all access over the loopback interface.  This could
# be tightened as well, but to do so would effect some of
# the administrative functions.
restrict 127.0.0.1


# -- CLIENT NETWORK -------
# Permit systems on this network to synchronize with this
# time service.  Do not permit those systems to modify the
# configuration of this service.  Also, do not use those
# systems as peers for synchronization.
# restrict 192.168.1.0 mask 255.255.255.0 notrust nomodify notrap


# --- OUR TIMESERVERS -----
# or remove the default restrict line
# Permit time synchronization with our time source, but do not
# permit the source to query or modify the service on this system.

# restrict mytrustedtimeserverip mask 255.255.255.255 nomodify notrap noquery
# server mytrustedtimeserverip



# --- NTP MULTICASTCLIENT ---
#multicastclient                        # listen on default 224.0.1.1
# restrict 224.0.1.1 mask 255.255.255.255 notrust nomodify notrap
# restrict 192.168.1.0 mask 255.255.255.0 notrust nomodify notrap



# --- GENERAL CONFIGURATION ---
#
# Undisciplined Local Clock. This is a fake driver intended for backup
# and when no outside source of synchronized time is available. The
# default stratum is usually 3, but in this case we elect to use stratum
# 0. Since the server line does not have the prefer keyword, this driver
# is never used for synchronization, unless no other other
# synchronization source is available. In case the local host is
# controlled by some external source, such as an external oscillator or
# another protocol, the prefer keyword would cause the local host to
# disregard all other synchronization sources, unless the kernel
# modifications are in use and declare an unsynchronized condition.
#
server  127.127.1.0     # local clock
server 0.vmware.pool.ntp.org
server 1.vmware.pool.ntp.org
server 2.vmware.pool.ntp.org

fudge   127.127.1.0 stratum 10

#
# Drift file.  Put this in a directory which the daemon can write to.
# No symbolic links allowed, either, since the daemon updates the file
# by creating a temporary in the same directory and then rename()'ing
# it to the file.
#
driftfile /var/lib/ntp/drift
broadcastdelay  0.008

#
# Authentication delay.  If you use, or plan to use someday, the
# authentication facility you should make the programs in the auth_stuff
# directory and figure out what this number should be on your machine.
#
authenticate yes

#
# Keys file.  If you want to diddle your server at run time, make a
# keys file (mode 600 for sure) and define the key number to be
# used for making requests.
#
# PLEASE DO NOT USE THE DEFAULT VALUES HERE. Pick your own, or remote
# systems might be able to reset your clock at will. Note also that
# ntpd is started with a -A flag, disabling authentication, that
# will have to be removed as well.
#
keys            /etc/ntp/keys

server 192.168.1.100

ntpdate -u timeserver.local

If the date is incorrect and you wish to reset it you would enter the command with the -s switch and specify date in mm/dd/yyyy format.

# date -s "12/29/2007 23:48"

Once you have set the date, you will want to ensure that the hardware clock matches your newly entered date. We can do this with the hwclock command described below.

# hwclock

If we want to synchronise the hardware clock with the service console date and time, we use the following:

# hwclock -systohc
 

# cal -3
    March 2006            April 2006             May 2006
Su Mo Tu We Th Fr Sa  Su Mo Tu We Th Fr Sa  Su Mo Tu We Th Fr Sa
          1  2  3  4                     1      1  2  3  4  5  6
 5  6  7  8  9 10 11   2  3  4  5  6  7  8   7  8  9 10 11 12 13
12 13 14 15 16 17 18   9 10 11 12 13 14 15  14 15 16 17 18 19 20
19 20 21 22 23 24 25  16 17 18 19 20 21 22  21 22 23 24 25 26 27
26 27 28 29 30 31     23 24 25 26 27 28 29  28 29 30 31
                      30

Surprisingly useful!

passwd <user>

Remember that passwords are not stored in the /etc/passwd file, but in the file /etc/shadow 

If you are ever needing to reset an unknown root account password, then it is this utility you would run after booting into Linux single user mode.
 

This software maintains an in-memory database on active nodes in the cluster and uses heartbeats to co-ordinate the active and passive nodes. It is suggested that you configure service console with 2 Ethernet interfaces to remove any single point of failure.

This is a piece of licensed Legato software which itself has been renamed to EMC AutoStart.

This component has a very high dependency upon fully functional host name resolution. So before you enable VMware HA, check the following files

/etc/hosts
/etc/FT_HOSTS
/etc/resolv.conf
/etc/vmware/esx.conf

to ensure accuracy. One thing you can do to check the name resolution functionality before enabling HA is run

hostname -s

to return the short name of the service console. If this fails, then the HA configuration WILL fail.

The log file for VMware HA in ESX 3.0.x can be found in the service console in the directory

/opt/LGTOaam512/

and for ESX 3.5 can be found in

/opt/VMware/

To avoid split brain scenarios, an ESX server can determine if it has become isolated from other servers and we can configure that servers' isolation response. If the AAM component loses contact with the other nodes in the HA cluster, it attempts to contact the configured default gateway for service console using ICMP echo request (PING). If this fails, then the ESX host is isolated. If your default gateway suppresses ICMP echo requests, then we can configure an alternate IP address called the das.isolationaddress. From ESX 3.5, you can configure multiple isolation addresses so that you can configure a host with more that one address to attempt contact with before declaring itself isolated.

[root@esx1host] # ifconfig vswif0
vswif0    Link encap:Ethernet  HWaddr 00:50:56:49:96:03
          inet addr:192.168.1.7  Bcast:192.168.1.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:4867312 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1980227 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:1632239875 (1556.6 Mb)  TX bytes:138260324 (131.8 Mb)

Notice this is a quick way of viewing your COS virtual MAC address alongside the IP address. Also note, you don't see the additional optional IP parameters like gateway and DNS servers.

If you are testing frame sizes, you can force ping not to fragment with the -f switch.
 

[root@esx1host sbin]# arping -I vswif0 -c 2 192.168.1.1
ARPING 192.168.1.1 from 192.168.1.7 vswif0
Unicast reply from 192.168.1.1 [00:50:56:48:F3:AC] 0.912ms
Unicast reply from 192.168.1.1 [00:50:56:48:F3:AC] 0.765ms
Sent 2 probes (1 broadcast(s))
Received 2 response(s)

Notice in the reply we see the MAC address of the target for the

[root@esx1host]# arp -a
vc.lab.taupoconsulting.com (192.168.1.200) at 00:0C:29:8D:F3:65 [ether] on vswif0
remote7.lab.taupoconsulting.com (192.168.1.70) at 00:50:56:84:19:56 [ether] on vswif0
remote7.lab.taupoconsulting.com (192.168.1.70) at 00:50:56:84:19:56 [ether] on vswif0

It's unlikely you will need static arp entries, but it can be done using the -s switch.

The output of this tool provides a load of information about the network cards, but of particular interest now is the support for Wake-on-LAN (WoL). DPM makes use of this NIC feature and so we need to check that our NICs both support the function AND have the function enabled. The ethtool allows us to view and set this functionality.

# ethtool vmnic1
Settings for vmnic1:
        Supported ports: [ TP ]
        Supported link modes:   10baseT/Half 10baseT/Full
                                100baseT/Half 100baseT/Full
                                1000baseT/Full
        Supports auto-negotiation: Yes
        Advertised link modes:  10baseT/Half 10baseT/Full
                                100baseT/Half 100baseT/Full
                                1000baseT/Full
        Advertised auto-negotiation: Yes
        Speed: 100Mb/s
        Duplex: Full
        Port: Twisted Pair
        PHYAD: 1
        Transceiver: internal
        Auto-negotiation: on
        Supports Wake-on: g
        Wake-on: g
        Link detected: yes

If we noted that our NIC supported WoL but it was not currently enabled, then we could use this tool to effect the change.

# ethtool -s vmnic1 wol g

showmount –e nfsserver

This command can be specified with the hostname name or IP address of the NFS server holding the exported directories. Remember that by default the service console will block nfsClient traffic. You will need to use esxcfg-firewall to open up that port.

service portmap start

And you can ensure this service is launched at boot time using the chkconfig command. Also remember that by default nfsClient is blocked by the service console firewall.

[root@esx1host root] # vcbVmName -h vcserver -u vcadminuser -p secret -s ipaddr:10.0.0.1
FoundVM

vcbRestore /remotenfs/backups/vm

However, as of VirtualCenter 2.5 (with integrated VMware Converter) we have the ability to restore VCB VM archives directly into ESX using the VMware Converter import function. This is a huge step forward in simplifying recovery.
 

If there are problems with the VirtualCenter service starting and then stopping almost immediately or a few seconds later, then check your ODBC database string and then the health of the the database server. We have seen this when the database runs out of disk space; check if the log space is full on the DB server, many clients forget about regular backup of this database. When troubleshooting the VirtualCenter service you can try VirtualCenter in stand-alone mode. This is done by invoking the following command at the Windows command line

vpxd -s

You will get interactive logging of the start-up activity helping you to pinpoint where the problem is.

If all else fails, you can always re-initialize the VirtualCenter database, however we would not recommend this. By re-initializing the VirtualCenter database you are wiping out all VC data!! If you do want this, then use the -b command switch to vpxd.

There are a number of configuration changes to VirtualCenter we can make in this file, but as of VC 2.5, one such change you may wish to make is the disabling of "Guided Consolidation". This feature, shown just as a consolidation button in the VI client, is intended to help small customers select which physical Windows hosts are suitable for consolidation and then guide them to perform the physical to virtual migration.

If you have already been through the consolidation process, then you don't need this feature. It makes sense to disable the feature if you are not using it as this should improve VC performance. To disable Guided Consolidation, simply edit the vpxd.cfg file on the VC management server and add the lines:

<vcp2v>
   config.vcp2v.dontStartConsolidation = true
</vcp2v>

You can get rid of the Guided Consolidation feature after VirtualCenter install by executing the following at the Windows command line on the VirtualCenter server.

msiexec /qn /x {2A2750C9-E14E-4635-8595-C1CD214445B0}

One of the main reasons you may want to edit this file is if you wish to change the directory that patches are downloaded into, i.e. the patch store. The default location is on the C:\ drive which may not be adequately sized; there are a considerable number of patches to download to offer OS and application patch remediation, totally many gigabytes.

To start a download, simply enter the command

vmware-umds --download

Once the updates are downloaded, we can export them. This means we copy the patches from the download directory to another path. The intended purpose of exporting is to copy all or a subset of the downloaded patches to a location that will then be made av