Esx Boot Process

ESX Server 3.0.x/3.5/3i Boot Process

1.Boot loader in MBR points to the boot device 2.Grub.conf lists the boot menu options. 3.Selected menu provides: •Location of root partition. Uses UUID instead of device name (e.g. /dev/sda) •RAM Disk file name relative to /boot location ESX Server 3i Boot Process

•Boot loader in MBR points to the boot device •initrd (initial Ram disk) is loaded ESXi Boot Sequence ESXi firmware boot starts from grub screen 1.Hypervisor loads necessary drivers 2.Hypervisor runs config scripts 3.Hypervisor starts daemons (services) 4.Boot process ends when DCUI screen is loaded •Alt+F2 : DCUI (Default) •Alt+F1: inactive console

•Alt+F11 : Summary information (version, server, CPU, memory) •Alt+F12 : vmkernel log The ESX Boot Process There are several steps to the boot process. LILO LILO (or the “Linux Loader”) is a boot loader application (similar to ntloader for Windows) that the system reads when it boots from the hard drive. Based on the information contained in /etc/lilo.conf file, the system begins its boot process. The default boot option for LILO within ESX is to boot and load the VMkernel. The /etc/lilo.conf file also contains information on how the COS should be configured as it is booting. This information contains the amount of memory allocated to it and the devices that are configured for COS use. Many of the LILO configuration items are controlled by the vmkpcidivy command. Console Operating System After LILO properly initializes the boot instructions the COS begins to load. The majority of the boot process is contained in the COS. Most of these steps are used to prepare the VMkernel to take control of the hardware resources. init The first process that the COS executes is init. This process reads the /etc/inittab file and determines the system runlevel that should be executed. (A Linux runlevel determines what services are started on the server and the order in which they are started.) Varying runlevels on a Linux system is comparable to the various boot options available on a Windows server such as “Safe Mode” or “Command Prompt Only.” The default system runlevel for ESX is 3, which means the system will boot and present a console for system login. Based on this value the COS will run the scripts contained in the /etc/rc.d/rc3.d directory during the boot process. /etc/rc.d/rc3.d The /etc/rc.d/rc3.d directory actually contains symbolic links to start scripts in the /etc/init.d directory. By running an “ls” command in the /etc/rc.d/rc3.d directory you will see some scripts that begin with a K and some that begin with an S. Scripts that begin with a K are used to stop (or “kill”) a service during the boot process (or ensure it is not running) and scripts beginning with an S are used to start a service. You will also notice a number after the S or the K in the script’s file name. These determine the order the script is run, starting at 0 and going up to 99. The S scripts are executed in ascending number

order, whereas the K scripts are executed in descending order. The order of the K or S values in the file have no meaning when it comes to what order a script runs in. S00vmkstart If you run an “ls –l” command in the scripts directory you’ll notice that the S00vmkstart command actually links to a script called vmkhalt. By running this script first, VMware ensures that there are no VMkernel processes running on the system during the boot process. S10network The network script (S10network) starts the TCP/IP services on the COS and assigns the IP address and hostname of the system. S12syslog The syslog script starts the daemon that processes system logs. Starting this script allows the remainder of the boot process to be logged. After the VMkernel begins to load it also provides a mechanism to capture the log files generated by the VMkernel for review when errors occur. S56xinetd The xinetd script starts the services required for the COS to handle incoming requests for access. Each application that can be started by xinetd has a configuration file in /etc/xinetd.d. If the “disable = no” flag is set in the configuration file of a particular application then xinetd starts the application. (Yeah it’s a double-negative.) The most important application that is started here is the vmware-authd application which provides a way to connect and authenticate to ESX to perform VMkernel modifications. S90vmware This is where the VMkernel finally begins to load. The first thing that the VMkernel does when it starts is load the proper device drivers to interact with the physical hardware of the host. You can view all the drivers that the VMkernel may utilize by looking in the /usr/lib/vmware/vmkmod directory. Once the VMkernel has successfully loaded the proper hardware drivers it starts to run its various support scripts: • The vmklogger sends messages to the syslog daemon and generates logs the entire time the VMkernel is running. • The vmkdump script saves any existing VMkernel dump files from the VMcore dump partition and prepares the partition in the event that the VMkernel generates unrecoverable errors.

Next the VMFS partitions (the partitions used to store all of your VM disk files) are mounted. The VMkernel simply scans the SCSI devices of the system and then automatically mounts any partition that is configured as VMFS. Once the VMFS partitions are mounted the VMkernel is completely loaded and ready to start managing virtual machines. S91httpd.vmware One of the last steps of the boot process for the COS is to start the VMware MUI (the web interface for VMware management). At this point the VMkernel has been loaded and is running. Starting the MUI provides us with an interface used to graphically interact with ESX. Once the MUI is loaded a display plugged into the host’s local console will display a message stating everything is properly loaded and you can now access your ESX host from a web browser.