cat > /etc/resolv.conf << DNS
nameserver 172.30.0.2 nameserver 172.30.0.3 DNS
# Link vSwitch0 used for Service Console communication to vmnic2 if the vmnic0 was not correct
/usr/sbin/esxcfg-vswitch -U vmnic0 vSwitch0 /usr/sbin/esxcfg-vswitch -L vmnic1 vSwitch0
# Add a vmkernel port for NAS access named NFSPort, with IP address of 172.30.0.101, and a default gateway of 172.30.0.1 (if required for routing)
/usr/sbin/esxcfg-vswitch -A NFSAccess vSwitch0
/usr/sbin/esxcfg-vmknic -a -i 172.30.0.101 -n 255.255.255.0 NFSport /usr/sbin/esxcfg-route 172.30.0.1
# Add an NFS datastore named NFSDatastore01 with an NFS server at 172.30.0.100 and a shared directory of ISOImages
/usr/sbin/esxcfg-nas -a -o 172.30.0.100 -s /ISOImages NFSDatastore01
# Enable the Service Console firewall to allow ntp and iSCSI client firewall ports
/usr/sbin/esxcfg-firewall -e ntpClient
/usr/sbin/esxcfg-firewall -e swISCSIClient
# Add a vmkernel port named VMotion on a virtual switch named vSwitch1. The VMkernel
port will have an IP address of 172.29.0.105
# and a subnet mask of 255.255.255.0
/usr/sbin/esxcfg-vswitch -a vSwitch1
/usr/sbin/esxcfg-vswitch -A VMotion vSwitch1
/usr/sbin/esxcfg-vswitch -L vmnic0 vSwitch1
/usr/sbin/esxcfg-vmknic -a -i 172.29.0.105 -n 255.255.255.0 VMotion
# Add a vswitch named vSwitch2 with a virtual machine port group named ProductionLAN
/usr/sbin/esxcfg-vswitch -a vSwitch2
/usr/sbin/esxcfg-vswitch -L vmnic2 vSwitch2 /usr/sbin/esxcfg-vswitch -A ProductionLAN vSwitch2
# Set up time synchronization for ESX Server
cat > /etc/ntp.conf << NTP
restrict default kod nomodify notap noquery nopeer
restrict 173.30.0.111
172.30.0.111
fudge 127.127.1.0 stratum 10
driftfile /etc/ntp/drift
broadcastdelay 0.008
authenticate yes
keys /etc/ntp/keys
NTP
cat > /etc/ntp/step-tickers << STEP
172.30.0.111
STEP
/sbin/service ntpd start
/sbin/chkconfig --level 3 ntpd on
# Update system clock
/sbin/hwclock --systohc --utc
# The --utc setting in the "timezone" command above eliminates the need for updating
the clock file
#cat > /etc/sysconfig/clock << CLOCK
#ZONE="UTC"
#UTC=true
#ARC=false
#CLOCK
# Allow incoming/outgoing communications on the Service Console via SSH.
esxcfg-firewall -e sshServer
esxcfg-firewall -e sshClient
# Rename the S11Post_Install_Config file to S11Post_Install_Complete after first execution. Since file name will now be incorrect it will
# not be triggered in subsequent ESX Server boot sequences. EOF dictates end of file.
mv /etc/rc.d/rc3.d/S11Post_Install_Config/etc/rc.d/rc3.d/S11Post_Install_complete
EOF
# Make the S11servercfg file an executable
/bin/chmod +x /etc/rc.d/rc3.d/S11Post_Install_Config
Postinstallation Configuration
Once the installation of ESX Server is complete, there are several postinstallation changes that either must be set or are just strongly recommended. Among these configurations are adjusting the amount of RAM allocated to the Service Console, changing the physical NIC used by the Service Console, and configuring the ESX Server host to synchronize with an external Network Time Protocol (NTP) server.
Service Console NIC
During the installation of ESX Server, the NIC selection screen creates a virtual switch bound to the selected physical NIC. The tricky part, as noted earlier, is choosing the correct PCI address that corresponds to the physical NIC connected to the physical switch that makes up the logical IP subnet from which the ESX Server will be managed. The problem often arises when the wrong PCI address is selected, resulting in the inability to access the Service Console. Figure 2.32 shows the structure of the virtual networking when the wrong NIC is selected and when the correct NIC is selected.
Figure 2.32 The virtual switch used by the Service Console must be associated with the physical switch that makes up the logical subnet from which the Service Console will be managed.
Should the incorrect PCI address be selected, the result is an inability to reach the ESX Server Web Access page after the installation is complete. The simplest fix for this problem is to unplug the network cable from the current Ethernet port and continue trying the remaining ports until the web page is accessible. The problem with this solution is that it puts a quick end to any type of documented standard that dictates the physical connectivity of the ESX Server hosts in a virtual environment.
So what then is the better fix? Is a reinstallation in order? If you like installations, go for it, but there is something much better. A quick visit to the command line and this problem is solved:
Sometimes It's All About the CaseRemember that ESX Server holds its roots in Linux and therefore any type of command-line management or configuration will always be case sensitive.
1. Log in to the console of the ESX Server using the root user account.
2. Review the PCI addresses of the physical NICs in the server by typing the following command:
esxcfg-nics -l
3. The results, as shown in Figure 2.33, will list identifying information for each NIC. Note the PCI addresses and names of each adapter.
Figure 2.33 The esxcfg-nics command provides detailed information about each adapter in an ESX Server host.
4. Review the existing Service Console configuration by typing the following command:
esxcfg-vswitch -l
5. The results, as shown in Figure 2.34, will display the current configuration of the Service Console port association.
Figure 2.34 The esxcfg-vswitch command provides information about the current Service Console configuration.
6. To change the NIC association, the existing NIC must be unlinked by typing the following command:
esxcfg-vswitch -U vmnic# vSwitch#
In this example the appropriate command would be:
esxcfg-vswitch -U vmnic0 vSwitch0
7. Use the following command to associate a new NIC with the vSwitch0 used by the Service Console:
esxcfg-vswitch -L vmnic# vSwitch#
If still unsure of the correct NIC, try each NIC listed in the output from step 2. For this example, to associate vmnic1 with a PCI address of 08:07:00, the appropriate command would be:
esxcfg-vswitch -L vmnic1 vSwitch0
8. Repeat steps 6 and 7 until a successful connection is made to the Web Access page of the ESX Server host.
Service Console Memory
Adjusting the amount of memory given to the Service Console is not mandatory but is strongly recommended if you have to install third-party applications into the console operating system. These third-party applications will consume memory available to the Service Console. As noted earlier, the Service Console is only granted 272MB of RAM by default, as shown in Figure 2.35, with a hard-coded maximum of 800MB.
Figure 2.35 The Service Console is allocated 272 MB of RAM by default.
The difference of 528MB is, and should be, negligible in relation to the amount of memory in the ESX Server host. Certainly an ESX Server host in a production network would not have less than 8GB of memory. Even that would be the low end. So adding 528MB of memory for use by the Service Console does not place a significant restriction on the number of virtual machines a host is capable of running due to lack of available memory.