Contents 1.0 Introduction

4

1.1 Reading this Document 1.2 Overview 1.3 Definitions 1.3.1 What is Microsoft Windows Deployment Service (WDS)? 1.3.2 What is the Microsoft Windows Automated Installation Kit? 1.3.3 What is the Preboot Execution Environment? 1.3.4 What is a ks.cfg File? 1.3.5 What are the initrd.img and vmlinuz Files?

4 4 4 4 4 4 4 5

2.0 Deployment Infrastructure Overview

5

2.1 Overview 2.2 Pre-requisites 2.3 Hardware and Software Requirements

5 5 5

3.0 Preparing the Automated Deployment

7

3.1 Configuration Overview 3.2 Running the win2k302 Installation and Configuration Scripts

7 8

4.0 ESX Scripted Deployments

8



8 8 9 9 10 10 10

4.1 Overview 4.2 ESX 3.5 – Basic Scripting 4.2.1 Using the ks.cfg File 4.3 ESX 4.0 – Basic Scripting 4.3.1 Root Password 4.3.2 Network Configuration 4.3.3 Using the ks.cfg File



5.0 Advanced Scripting

11

5.1 ks.cfg %pre Section 5.1.1 Example Script: Using the %pre Section 5.2 ks.cfg %post Section 5.3 Example Script: Using the %post Section (ESX 3.x) 5.3.1 What is the rc.local File? 5.3.2 %post Section A 5.3.3 %post Section B 5.3.4 %post Section C 5.3.5 %post Section D 5.3.6 Example Script: postinst01.sh 5.3.7 The Full Process 5.4 Example Script: Using the %post Section (ESX 4.x) 5.4.1 ESX 4.x %post Section Modifications

11 11 12 13 13 13 13 14 14 14 14 14 15

6.0 The Xtravirt Build Method

16

6.1 Demonstration 6.2 Detailed Explanation and Steps 6.2.1 The xtravirtmethodks.cfg File: Overview 6.2.2 The xtravirtmethodks.cfg File: %pre Section 6.2.3 The xtravirtmethodks.cfg File: Common Section 6.2.4 The xtravirtmethodks.cfg File: Host Specific Kickstart Commands 6.2.5 The xtravirtmethodks.cfg File: Individual %post Scripts 6.3 Adding a New Host

Appendix A

A1 Using DHCP Reservations to Allocate IP Addresses to ESX Hosts A2 Sample Code A2.1 Create a vSwitch A2.2 Delete a vSwitch A2.3 Create a Port Group A2.4 Delete a Port Group

16 17 17 18 18 19 19 19

20

20 22 22 22 22 22

3





A2.5 Configure a VLAN ID for a Specific Port Group A2.6 Remove a VLAN ID for a Specific Port Group on a vSwitch A2.7 Configure a VLAN ID for all Port Groups on a vSwitch A2.8 Remove a VLAN ID for all Port Groups on a vSwitch A2.9 Link a Network Adaptor to a vSwitch A2.10 Un-link a Network Adaptor from a vSwitch A2.11 Configure a Logon Message (for SSH Connections) A2.12 Configure MOTD Message A2.13 Configure Firewall A2.14 Permit Root Logon via SSH A2.15 Add a Local Account A2.16 NTP Configuration

Appendix B: Manual WDS\IIS Configuration

B1 Creating a Basic Windows PE Image File B2 Installing WDS, FTP Components (Manually) B3 Install IIS and Create FTP Site B4 Configure WDS Services B5 Adding Support for ESX3.5 B5.1 Configuring the Boot Menu B5.2 Creating the ESX 3.5 Distribution Point B5.3 Testing a PXE Boot Installation of ESX 3.5 B6 Adding Support for ESX 4.0 B6.1 Enable ESX 4.0 Boot Menu B6.2 Creating the ESX 4.0 Distribution Point B6.3 Adding Scripted Build Support to ESX 3.5 B7 Adding Support for ESX 4.0 B7.1 Adding Scripted Build Support to ESX 4.0

22 22 22 23 23 23 23 24 24 24 25 25

26 26 26 27 27 28 28 29 30 30 30 31 31 31 31

4

1.0 Introduction 1.1 Reading this Document The following standards are used throughout this document. To view the embedded videos, Acrobat 6.0 or higher is required, and may require installation of the Adobe Flash plugin. 1. Sample text

Indicates an action is required, eg: install or configure a component

# Sample text

An example, used to illustrate a concept

1.2 Overview This e-book discusses scripted builds for VMware ESX Server, including optional usage of Microsoft WDS server to deploy a scripted ESX build using PXE boot. Whilst many resources for VMware ESX Server deployment already exist, this guide delves much deeper into scripted technologies, which allow automated provisioning with flexible scripted builds. Although this guide has been written with a focus on ESX4, ESX3.5 is also covered. The e-book also documents the Xtravirt build methodology. This is a custom approach which has enabled many of our customers to rapidly provision ESX servers to a consistent and standardised level. The following table outlines each chapter and it’s purpose and context. Chapter

Description

1.0

E-book overview and key definitions

2.0

Manual tasks to create an automated deployment environment

3.0

Run scripts provided with e-book to configure the automated deployment environment

4.0

How to use ks.cfg files for scripting, and steps to take for a basic configuration

5.0

Examples of advanced scripting for ks.cfg files

6.0

Explanation of an Xtravirt build methodology and how to apply it

The appendices in this book also provide additional scripting samples and manual configurations should the reader choose not to use the automation scripts provided.

Key scripts are provided in the correct file format within a downloadable iso rather than copy/pasting from the e-book. Information about use of the .iso is provided in Chapter 3. The concepts in this book are discussed at an advanced level and assumes the reader has experience of VMware ESX Server, and familiarity of scripting and Microsoft WDS.

1.3 Definitions 1.3.1 What is Microsoft Windows Deployment Services (WDS)? Windows Deployment Services (WDS) is a network-based installation technology provided by Microsoft. It is the successor of Microsoft’s legacy Remote Installation Services (RIS). WDS aids customers in deploying Windows Vista, Windows Server 2008, Windows 2003 Server and Windows XP. WDS deploys disked based images using the proprietary Microsoft WIM format. WDS utilizes PXE boot, resulting in images which can be deployed rapidly to multiple machines simultaneously. WDS is a role included in all editions of Windows Server 2008 and was added to Windows 2003 Server with the introduction of Service Pack 2. It is also shipped within the free of charge Microsoft WAIK toolkit.

1.3.2 What is the Microsoft Windows Automated Installation Kit? The Microsoft Windows Automated

Installation Kit (WAIK) is a collection of tools written by Microsoft. The tools are provided to aid customers deploying Windows. The toolkit provides tools to create and edit images, the Windows Pre-installation Environment (Windows PE), the Windows System Image Manager and many more.

1.3.3 What is the Preboot Execution Environment? The Preboot Execution Environment (PXE) is an environment that can be used to boot computers to a network-connected state, regardless of type or hardware. The environment is booted over the network across the network adaptor. PXE functionality must be supported by the machine BIOS and network adaptor. All modern machines generally support PXE; and always check that it is enabled in the BIOS when configuring these types of environments.

1.3.4 What is a ks.cfg File? A ks.cfg (kickstart) file provides configuration information for the Linux installer process. The Linux installer process is used to install ESX on to the target hardware. Typically a manual installation requires user input at the console, ie: to provide partitioning information and configure regional settings. The ks.cfg provides preset answers resulting in an automated installation, often referred to as scripted installation, scripted build or unattended build.

5

1.3.5 What are the initrd.img and vmlinuz Files? The initrd.img or initial ram disk is a file system that is used to boot a Linux file system. The vmlinuz file contains the system kernel. These files are used during the installation process.

2.0 Deployment Infrastructure Overview 2.1 Overview The deployment platform is based upon a compact virtualization infrastructure see Figure 2-1.

Figure 2-1: Deployment Infrastructure Overview Name

win2k301

This setup can be achieved using a physical environment or a mixture of both. For the purposes of this scenario, a PC which meets a minimum hardware specification has been used.

Hardware Compatibility

Workstation 7

Guest Operating System

Windows 2003 Server R2 (with SP2)

Role(s)

Windows Domain Controller, DHCP, DNS

IP Address

192.154.30.1

2.2 Pre-requisites

Subnet Mask

255.255.255.0

DNS & Gateway

192.154.30.1

Memory

384MB

Hard Disk

40GB (not pre-allocated)

CD/DVD

Yes, connected

Network Adaptor

Connected to host only VMNET

Processors

1

Domain Name



Three virtual machines are required to be created before proceeding. The specifications for the 3 virtual machines are outlined in tables within Section 2.3. All VM’s should be created at this point. VM 3 will be the target for the scripted deployment.

2.3 Hardware and Software Requirements The minimum requirements consist of a PC with 3GB RAM and AMD-V / Intel VT enabled processor, with at least 20GB of free disk space VMware Workstation 7, Windows 2003 SP2 R2, ESX 3.x, ESX 4.x media, and the Microsoft Windows Table 2-1: The virtual machine will require Active Directory, DNS and DHCP roles installed and configured.

DHCP/DNS Information Start IP Address

192.154.30.220

End IP Address

192.154.30.254

Limited to

1 Hour(s)

Scope Options 003 Router

192.154.30.1

006 DNS Servers

192.154.30.1

015 DNS Domain Name



DNS Information

Forward and reverse lookup zones should be created

Required Software

None

Table 2-1: Virtual Machine 1 - win2k301

6

Automated Installation Kit (Microsoft WAIK).

Name

win2k302

Hardware Compatibility

Workstation 7

Guest Operating System

Windows 2003 Server R2 (with SP2)

Role(s)

Windows WDS and IIS FTP Server

IP Address

192.154.30.2

Subnet Mask

255.255.255.0

DNS & Gateway

192.154.30.1

Next Steps

Memory

384MB

1. Install VMware Workstation on a PC

Hard Disk 1

40GB Operating System (not pre-allocated)

Hard Disk 2

40GB for WDS and FTP repositories (not pre-allocated)

2. Create and configure VM’s win2k301, win2k302 & esxtest - see Tables 2-1, 2-2, 2-3

Note: This must have the Windows drive letter E: assigned Network Adaptor

Connected to ‘host only’ VMNET

Processors

1

Domain Member

Yes

Required Software

Microsoft Dot Net Framework 2.0, Microsoft MSXML 6 (provided in learning_materials.iso) Microsoft WAIK toolkit (download the latest version from Microsoft)

Table 2-2: Virtual Machine 2 - win2k302

Name

esxtest

Hardware Compatibility

Workstation 7

Guest Operating System

VMware ESX / ESX Server 4.0

Role(s)

ESX Server (deployed via scripted build)

IP Address



Subnet Mask



DNS & Gateway



Memory

2048MB

Hard Disk

40GB (not pre-allocated)

CD/DVD

Connected

Network Adaptor

Connected to ‘host only’ VMNET

Processors

1

Domain Member

No

Table 2-3: Virtual Machine 3 - esxtest

Note that all IP addresses referred to in this document are based on the scenario outlined. You may require or choose to use alternative IP addressing.

3. Ensure that the pre-requisite software for win2k302 is installed before proceeding further, or subsequent steps will fail For the esxtext VM(Table 2-3), the VMNET switch should be a host only connection. For this scenario the connection should not be running any DHCP services provided by VMware Virtual Networking and should be confirmed before proceeding. If DHCP is enabled on the virtual network then it should be disabled as VM1 (win2k301) will be providing DHCP. The status of any VMNET can be checked in the VMware Virtual Network Editor.

7

3.0 Preparing the Automated Deployment 3.1 Configuration Overview Virtual machine 2 (win2k302) requires additional Windows components, folders and files. Accompanying this e-book is an iso file named learning_materials.iso containing a scripted installation of all of the components, as well configuration of folders and files. These scripts carry out the tasks illustrated in Figure 3-1. Follow the steps in the next section to apply the scripts provided.

Figure 3-1: Win2k302 Scripted Configuration Process

Once complete, the PXE boot environment, FTP deployment repository and initial PXE boot menu will have been configured. ESX 3.5 and ESX 4.0 files are copied to the FTP repository location. Note: The above tasks can be carried out manually if you do not wish to use the scripts. The manual process can be found in Appendix B.

8

3.2 Running the win2k302 Installation and Configuration Scripts These scripts will carry out the installation of required Windows components. Once complete the server will reboot. When next logged on, the configuration process will continue. Follow the onscreen prompts when required to provide media for ESX3.5 and ESX4.x - see Video 3-1; note, to enlarge the video, adjust the size from the Adobe PDF View menu. Next Steps

2. Copy the CD contents to the root of the E: drive. 3. Once copied, disconnect the learning_ materials.iso and connect the CD to the Windows 2003 Standard Server R2 (with SP2) ISO CD 1 (not provided). 4. Open a command prompt by entering cmd.exe from the Start -> Run dialogue 5. Change the working directory to the E: drive and then enter the following command (typed as one line - refer Figure 3-2):

1. Ensure all prevous pre-requisites have been completed. Connect the learning_ materials.iso file to the win2k302 VM.

cscript.exe 1_Install_Deployment_ Server.vbs

4.0 ESX Scripted Deployments 4.1 Overview This chapter discusses scripted deployment methology for both ESX 3.5 and ESX4. It walks through basic concepts and how to apply them.

4.2 ESX 3.5 Basic Scripting Below shows the contents of a sample ks.cfg file for ESX 3.5. Each command is commented to provide information on its use. # specify ftp path to esx35 media url --url ftp://192.154.30.2/esx35 # specify the root password rootpw xtravirt # specify use of MD5 and shadow passwords file auth --useshadow --enablemd5

Figure 3-2: Start Installation and Configuration Script

# specify location of the boot loader bootloader --location=mbr # Set timezone timezone --utc Europe/London # Skip skipx # Perform an install install # Run install in text mode text # Use US English language lang en_US # Use US English language langsupport --default en_US # Use UK Keyboard keyboard uk # Don’t use a mouse mouse none # Reboot at the end of the install reboot # Disable firewall during kickstart process firewall –disabled # Accept the VMware provided EULA vmaccepteula %packages @ base %post

Video 3-1: Win2k302 Scripted Configuration Demonstration

Example 4-1: Sample ESX3.5 ks.cfg

9

4.2.1 Using the ks.cfg File Using the contents of the example41.txt file provided, support can be added for a scripted build to the WDS PXE boot system. Next Steps 1. Create a new ks.cfg file and name it ks.cfg 2. Copy the contents of the example41.txt file to it. Save and close.

The APPEND line passes commands and syntax to the Kernel during boot. These include the following: initrd

specifies the boot image to use

esx text

installer boots in text mode

ks

location of ks.cfg file

ksdevice=eth0

specifies which physical NIC to use as service console during installation

Powering on the esxtest VM and selecting the ESX 3.5 Scripted (ks.cfg) option will initiate a semi-unattended installation of ESX 3.5 (you will be prompted for network and disk information). Note: If the PXE boot fails, ie: no menu displayed, ensure that the WDS services are running correctly on the win2k302 VM.

3. Copy ks.cfg file to E:\ftp_deployment\ esx35\

An option needs to be provided so that during the PXE boot process a user can select the scripted installation method. The next steps show how to add an additional item to the boot menu. Note: The PXE boot menu is stored in a file called default, located in E:\ remoteinstall\Boot\x86\pxelinux. cfg\

Next Steps 1. Edit the default file using WordPad or similar. Add the following text to the end of the file. Entries are single continuous lines where shown wrapped. LABEL ESX35A MENU LABEL ESX3.5 Scripted (KS.CFG) KERNEL linux/vmlinuz-esx35 APPEND initrd=linux/ initrd-esx35.img esx text ks=ftp://192.154.30.2/esx35/ ks.cfg ksdevice=eth0

4.3 ESX4 Basic Scripting Below shows the contents of a sample ks.cfg file for ESX 4.0. Each command is commented to provide information on its use. # Accept the ESX License Agreement accepteula # Configure authentication for the host. Enables shadow password file and MD5based passwords authconfig --enableshadow --enablemd5 # Configure the bootloader. Sets the location to be the Master Boot Record of the disk bootloader --location=mbr # Removes all partitions on the first disk and overwrite existing VMFS partition clearpart --firstdisk --overwritevmfs # Partitioning Section - create partitions of sizes and types part /boot --fstype=ext3 --size=2000 --onfirstdisk part storage1 --fstype=vmfs3 --size=10000 --grow --onfirstdisk part None --fstype=vmkcore --size=100 --onfirstdisk # Creates the vmdk on the cos vmfs partition. virtualdisk cos --size=5000 --onvmfs=storage1 # Partitions the virtual disk. part / --fstype=ext3 --size=3040 --grow --onvirtualdisk=cos part swap --fstype=swap --size=256 --onvirtualdisk=cos # Allows all incoming connections via the ESX firewall during installation firewall --allowIncoming # Specifies the type of installation. URL = network install, network path to install files install url ftp://192.154.30.2/esx40 # Specify Keyboard Layout keyboard uk

The LABEL tag provides a unique name for this menu item. The MENU LABEL tag specifies the text that the user sees on the menu during the PXE boot process. The KERNEL tag specifies which Kernel to boot when this item is selected. In this case this is the ESX 3.5 kernel file copied during the scripted configuration process.

# Specify Timezone timezone --utc Europe/London # Tell the installer to automatically reboot after the install is complete reboot # Configure the root Password (can be optionally encrypted) rootpw xtravirt # Configure Network to obtain IP address and information from DHCP server network --bootproto=dhcp %pre %post

Example 4-2: Sample ESX4 ks.cfg

10

The script in Example 4-2 provides enough information for a partially automated installation of ESX4. However, there are a number of other optional entries which can provide additional configuration.

4.3.1 Root Password The root password is provided in the sample file in plain text. This presents an obvious security risk should an unauthorised person obtain the file. # Configure the root Password (can be optionally encrypted) rootpw xtravirt

Example 4-3: Plain text password

The root password can be encrypted in the ks.cfg file so that it cannot be read. The encrypted password can be generated from an ESX console - refer http://xtravirt.com/ xd10083. However, if you do not have an installation of ESX, there is a free MD5 password generator utility which can create an encrypted password. The utility runs on Windows systems and can be downloaded from http://xtravirt.com/xd10097.

Figure 4-1: If ESX hosts require a static IP address, then multiple ks.cfg files are typically needed

# configure Network to use static IP address, DNS and provide hostname Network –static –device=vmnic0 –ip=192.154.30.200 – gateway=192.154.30.1 – nameserver=192.154.30.1 – hostname=esxtest

Example 4-5: Static network configuration

4.3.2 Networking Config. This script instructs the ESX installer to obtain an IP address leased from a DHCP server for the service console. For evaluation or testing purposes this is acceptable, however in a production environment it is typical to specify a static IP. # configure Network to obtain IP address and information from DHCP server network --bootproto=dhcp

When using static IP addresses it soon becomes apparent that a ks.cfg file is required per server - see Figure 4-1. However there are alternative scripting techniques that can be used to counter this, and will be covered in later sections. The ESX and Virtual Center installation guide from VMware lists compatible ks.cfg scripting commands.

Example 4-4: ESX DHCP IP addressing

4.3.3 Using the ks.cfg File

To configure a static IP address the following information is required:

Using the contents of the example42.txt file provided, support can be added for a scripted build to the WDS PXE boot system.

--ip

ESX Server service console IP

--netmask

Subnet mask

--gateway

Defaul gateway

--nameserver

DNS server IP address. Only one can be specified at this stage

--hostname

FDQN hostname

--device

The physical NIC to assign to the service console

Next Steps

An option is required during the PXE boot process to allow a user to select the scripted installation. To do this we add an additional item to the boot menu. Note: The PXE boot menu is stored in a file called default, located in E:\ remoteinstall\Boot\x86\pxelinux. cfg\ Next Steps 1. Edit the default file using WordPad or similar. Add the following text to the end of the file. Entries are single continuous lines where shown wrapped. LABEL ESX40A MENU LABEL ESX4.0 Scripted (ks. cfg) KERNEL linux/vmlinuz-esx40 APPEND initrd=linux/ initrd-esx40.img text ks=ftp://192.154.30.2/esx40/ ks.cfg mem=512M url=ftp://192.154.30.2/esx40

1. Create a ks.cfg file and name it ks.cfg 2. Copy the contents of the example42.txt file to it. Save and close. 3. Copy ks.cfg to E:\ftp_deployment\ esx40\

The LABEL tag provides a unique name for this menu item. The MENU LABEL tag specifies the text that the user sees on the menu during the PXE boot process. The KERNEL tag specifies which Kernel

11

to boot when this item is selected. In this case this is the ESX 4 kernel file copied during the scripted configuration process. The APPEND line passes commands and syntax to the Kernel during boot. These include the following: initrd

Specifies the boot image to use

esx text

Installer boots in text mode

ks

Location of ks.cfg file

mem

Memory to allocate to the installer

url

Path to the ESX 4.x installation files (RPMS)

Powering on the esxtest VM will now display a new PXE boot menu item. When selected an unattended installation of ESX 4 will begin.

5.0 Advanced Scripting 5.1 ks.cfg %pre Section Although the sample ks.cfg file is sufficient to automatically deploy a generic ESX host, we can also inject unique personality for a server, eg: hostname, IP address. Through this customization there are also advanced techniques to minimise the number of ks.cfg files needed. In the ks.cfg sample files you may have noticed two tags in the file: %pre %post

Any command in the %pre section is executed before all other instructions in the ks.cfg file. Commands in the %post section are read and carried out after all other commands in the ks.cfg have been executed. Note: The location of the %pre and %post sections must be at the end of all other instructions in the ks.cfg file.

Figure 5-1: Overview of the ks.cfg processing model

The %pre section instructions are executed prior to loading the operating system on the host server. Due to this, only a handful of commands can be executed. Although this may seem limited, the %pre section is actually very useful.

5.1.1 Example Script: Using the %pre Section The following example allows custom information to be automatically added to the ESX server configuration during deployment. Using only the hostname, the ks.cfg file can install the server using a pre-allocated static IP address as well as providing DNS, gateway and subnet mask. In this example scenario the hostname of the ESX server is “host1”. The example script in Example 5-1 provides the code to insert in the %pre section of a ks.cfg file which will set the network configuration of an ESX server where the hostname is “host1”. %pre < /proc/cmdline sed ‘s/ /\n/g’ | grep ^myop_name > /tmp/boot_parameters . /tmp/boot_parameters if [[ “$myop_name” = “host1” ]]; then echo “network --bootproto=static --device=vmnic0 --ip=192.154.30.100 --gateway=192.154.30.1 --netmask=255.255.255.0 –nameserver=192.154.30.1 --hostname=host1” >> /tmp/xtravirt.network else echo “network --bootproto=dhcp” >> /tmp/xtravirt.network fi

Example 5-1: %pre section automation of ESX Server IP configuration

When host1 is PXE booted using this method, the PXE boot menu appears, and provides an option to select the ESX4.0 Scripted (ks.cfg) option. Pressing the tab key displays a line of text beneath the menu. This is the command line that is going to be executed by the installer as seen in Figure 5-2. All commands passed to the installer are automatically and temporarily stored in a file called /proc/cmdline. By simply typing commands on to the end of this line, further instructions can be passed to the installer. These can then act as a trigger for considerable installation configuration automation.

12

For example, adding the following command to the existing line - see Figure 5.2. myop_name=”host1”

Example 5-2: Adding a hostname at installation command line

When the administrator presses enter the installer starts the installation process. After processing the ks.cfg file it proceeds to execute the instructions in the %pre section. The instructions in the %pre section read all of the command line parameters. If a parameter was passed called myop_name as in the example, then it checks the value to see if it is equal to host1. if [[ “$myop_name” = “host1” ]]; then

Example 5-3: Code snippet of hostname check (refer Example 5-1)

If the value matches, a string of text is written to a file called xtravirt.network located in /tmp >> /tmp/xtravirt.network

Example 5-4: Code snippet of output to /tmp file (refer Example 5-1)

Note: --hostname=host1 entry can be a FQDN if required, e.g. host1. xtravirt.lab The string of text contains the ks.cfg networking script with all required syntax to set hostname, IP address, subnet mask, gateway and DNS server address. If the value is anything other than host1 then a different string is written to the file, configuring the host to use DHCP to obtain IP information. else echo “network --bootproto=dhcp” >> /tmp/xtravirt.network fi

Example 5-5: Code snippet of default DCHP configuration (refer Example 5-1)

The ks.cfg instructions outside of the %pre and %post sections are then executed. In this scenario the ks.cfg file default networking section has been amended. Originally the ks.cfg file had the following

Figure 5-2: Passing additional commands to the installer

entry for networking: # Configure Network to obtain IP address and information from DHCP server network --bootproto=dhcp

Example 5-6: Default ks.cfg networking configuration

Under this solution it has been replaced with the following: # Obtain networking settings from the /tmp/xtravirt.network file %include /tmp/xtravirt.network

Example 5-7: Modified ks.cfg networking configuration

This instructs the installer to read the contents of the /tmp/xtravirt.network file and execute them. The %pre section can easily be amended to take in to account multiple hosts by adding further information as per Example 5-8. This %pre script contains entries for 2 different hosts: “host1” and “host2”. Naturally this method can be scaled to as many hosts as needed, up to several hundred or more and only ever require one ks.cfg file, albeit a potentially long one. Reducing the configuration to a single ks.cfg for many hosts reduces management and complexity of ESX server deployments as well as deployment times.

Advert

%pre < /proc/cmdline sed ‘s/ /\n/g’ | grep ^myop_name > /tmp/boot_ parameters . /tmp/boot_parameters if [[ “$myop_name” = “host1” ]]; then echo “network --bootproto=static --device=vmnic0 --ip=192.154.30.100 --gateway=192.154.30.1 --netmask=255.255.255.0 --nameserver=192.154.30.1 --hostname=host1” >> /tmp/xtravirt. network elseif [[ “$myop_name” = “host2” ]]; then echo “network --bootproto=static --device=vmnic0 --ip=192.154.30.101 --gateway=192.154.30.1 --netmask=255.255.255.0 – nameserver=192.154.30.1 --hostname=host2” >> /tmp/xtravirt. network else echo “network --bootproto=dhcp” >> /tmp/xtravirt.network fi

Example 5-8: Automating multiple hosts

Additional command line instructions can be used in this manner to further refine scripted installations providing greater levels of managed flexibility.

5.2 ks.cfg %post Section The %post section is executed once the %pre and standard ks.cfg sections have been read and processed. This module is useful for configuring scripts to run following the next reboot, or run commands that were not available during the %pre or standard ks.cfg sections.

13

The following sub-sections outline how the %post section could be used historically with ESX 3.x installations, and how this has been improved upon with ESX 4.x.

5.3 Example Script: Using the %post Section (ESX 3.x) The following example enables a script to run upon start up following the automatic reboot at the end of the ESX installation process. To do this, the rc.local file is temporarily renamed and a replacement one is created in order to protect the original. Instructions are written in to this copy; examples being creation of local folders, allow SMB traffic through the ESX firewall, connect to an SMB share, and copy a script file to the local file system. Under this solution we configure the %post section into four key sections - see Figure 5-4.

5.3.1 What is the rc.local File? The rc.local file is common to most Linux distributions including ESX Server. The rc.local contents are executed after specific boot actions (referred to as run-level

Figure 5-3: Xtravirt ks.cfg %post 4-section process for ESX3.x

specific commands) have completed. In Windows terms it is similar to placing commands in the Start-up folder on the Windows start menu.

5.3.2 %post Section A Section A begins by telling the installer that the %post section exists in the ks.cfg file. Following the %post statement, the Linux cp (copy) command is used to create a backup of the original rc.local file.

%post # Save a copy of rc.local cp /etc/rc.d/rc.local /etc/rc.d/ rc.local.sav

Example 5-9: Code snippet of %post rc.local backup/copy (refer Figure 5-4)

The rc.local file is located in the /etc/rc.d folder. It is copied to the same location, in this example appending .sav to the end of the filename.

5.3.3 %post Section B Section B writes instructions into the rc.local file, which will be executed following next reboot of the host. # Set up rc.local cat >> /etc/rc.d/rc.local >’ symbols mean that all text from this point onwards will be appended to the rc.local file. Text will continue to be written until it reaches the text EOF1. The mkdir (make directory) command is used to create two subfolders under the /tmp folder, one

14

called script the other called mount. The esxcfg-firewall command is run to enable the smbClient exception. This will allow smb traffic to pass through the firewall. Next, the Linux mount command is used to mount (or in Windows terms, map a network drive) the postbuild folder, on 192.154.30.250 to the /tmp/mount folder on the host. A username and password are specified to authenticate with the target device. Finally, the contents of the mounted folder, /tmp/mount/ are copied to the local host under /tmp/script/. Within the folder is the file postinst01.sh.

5.3.4 %post Section C Section C makes the contents of the /tmp/ script folder executable. # Make script executable chmod +x /tmp/script/

Example 5-11: Code snippet of %post Section C - set execute permissions to instructions (refer Figure 5-4)

The Linux chmod command is used to mark the contents of the script folder as executable. This includes the postinst01. sh file.

5.3.5 %post Section D The final part of the %post section runs the postins01.sh file and tells cat to stop writing to the rc.local file. # Set postinst01.sh to run after reboot /tmp/postinstall/scripts/postinst01. sh EOF1

Example 5-12: Code snippet of %post Section D - set instructions to run upon next reboot (refer Figure 5-4)

5.3.6 Example Script: postinst01.sh

•

Configure NTP

•

Configure VMotion

The following simple example script postinst01.sh creates a virtual switch (vSwitch1) and links it to a separate physical network adaptor (nic 1).

•

Add local user accounts

•

Configure network policies

•

Configure login banners

•

Install and configure 3rd party hardware agents

Note: The code snippet below assumes that the physical nics exist in the machine. # Post ESX Server install configuration # Configure VM Production Network vSwitch setlabvswitch() { # Create vSwitch (vswitch1), create a portgroup (LAB), connect nic1 to it esxcfg-vswitch -a vSwitch1 esxcfg-vswitch –A LAB vSwitch1 esxcfg-vswitch -L vmnic1 vSwitch1 } # Call function setlabvswitch shutdown -r now exit 0

Example 5-13: Code snippet of post installation script

Most commands that can be executed at the ESX console can be used in the postinst01.sh script. As always, building a non-production ESX host and then testing out commands at the console is advisable before deploying to a live environment. Common tasks that can be carried out by the postinst01.sh script may include the following: •

Configure firewall rules (inbound / outbound exceptions)

•

Configure networking (virtual switches, port groups, vlans, hostname, DNS)

Figure 5-5: The complete build process including %pre, %post and postinst01.sh script

5.3.7 The Full Process Assuming the ks.cfg has been created correctly with the %pre and %post sections as well as SMB share and contents then the total build process would deploy as per Figure5-5.

5.4 Example Script: Using the %post Section (ESX 4) The major development in ESX 4 is that almost all of the native ESX console commands are available during the ESX 4.x installer phase, meaning that additional commands are available during the time that the %post section is executed. This is as opposed to writing out the commands in a script file as per ESX 3.x and waiting for reboot- see Section 5.3. This reduces time and complexity of ESX deployments. The amended ks.cfg file would look like the example in Example 5-14. We can see that a second reboot command is no longer required, and the installer will reboot the host once the %post section is complete. An example %pre section code has also been included for completeness. The %post section code in Example 5-14 assumes that the physical nics exist in the machine.

15

# Accept the ESX License Agreement accepteula # Configure authentication for the host - enable shadown password file and MD5based passwords authconfig --enableshadow --enablemd5

interpreter you wish to use for each statement. Errors generated from incorrect statements in %post section can be configured to be ignored or have the script stop processing if an error is found.

# Configure the bootloader - set the location to be the Master Boot Record of the disk bootloader --location=mbr

For specific information on the %post section, see the VMware ESX and vCenter Server Installation Guide.

# Remove all partitions on the first disk and overwrite existing VMFS partition clearpart --firstdisk --overwritevmfs

Although the %pre section executes prior to ESX package installation, the %pre section can execute statements for Bash and Python. Perl is not supported natively.

# Partitioning Section - create partitions of sizes and types part /boot --fstype=ext3 --size=2000 --onfirstdisk part storage1 --fstype=vmfs3 --size=10000 --grow --onfirstdisk part None --fstype=vmkcore --size=100 --onfirstdisk # Create the vmdk on the cos vmfs partition. virtualdisk cos --size=5000 --onvmfs=storage1 # Partition the virtual disk. part / --fstype=ext3 --size=3040 --grow --onvirtualdisk=cos part swap --fstype=swap --size=256 --onvirtualdisk=cos # Allow all incoming connections via the firewall firewall --allowIncoming # Specifies the type of installation - URL = network install, network path to install files install url ftp://192.154.30.4/esx40 # Specify Keyboard Layout keyboard uk # Specify Timezone timezone --utc Europe/London # Tell the installer to automatically reboot after the install is complete reboot # Configure the root Password (can be optionally encrypted) rootpw xtravirt # Obtain networking settings from the /tmp/xtravirt.network file %include /tmp/xtravirt.network %pre < /proc/cmdline sed ‘s/ /\n/g’ | grep ^myop_name > /tmp/boot_parameters . /tmp/boot_parameters if [[ “$myop_name” = “host1” ]]; then echo “network --bootproto=static --device=vmnic0 --ip=192.154.30.100 --gateway=192.154.30.1 --netmask=255.255.255.0 – nameserver=192.154.30.1 --hostname=host1” >> /tmp/xtravirt.network else echo “network --bootproto=dhcp” >> /tmp/xtravirt.network fi %post # Create vSwitch (vswitch1), create a portgroup (LAB), connect nic1 to it esxcfg-vswitch -a vSwitch1 esxcfg-vswitch –A LAB vSwitch1 esxcfg-vswitch -L vmnic1 vSwitch1

Example 5-14: Sample ESX4 ks.cfg with direct %post commands

6.0 The Xtravirt Build Method The Xtravirt Build method is the culimination of experimention and experience. This section describes the architecture of the Xtravirt solution, and all files and configurations have been prepackaged into the learning_materials.iso file packaged with this download. It is not intended to dictate the best method of deployment, more as another option, and is built upon the following ideals: •

Deployment of consistent configuration across all ESX hosts (example, vSwitches, portgroups)

•

Enable quick and simple addition of new host builds to the delivery mechanism

•

As much ‘hands off’ time as possible

•

Deployment through PXE boot process using WDS

For the purposes of this scenario, the following assumptions are made •

The only unique information per host is as follows:

5.4.1 ESX 4 %post Section Modifications

•

Disk partitioning requirements

The %post section commands that can be used under ESX 4.x provide greater flexibility than in previous versions. At the time that the %post section statements are executed, the ESX packages have been installed. These include the Python, Perl and Bash interpreters. The %post section can make use of all of the interpreters as you can specify which

•

Hostname

•

Service console IP address, netmask, nameserver, gateway

16 Each host requires a host.cfg file. This file contains the unique footprint for each host. The host.cfg file contains the following information: •

Disk partitioning requirements

•

Hostname

•

Service console IP address, netmask, nameserver, gateway

Additionally each ESX host requires a host.vmotion file which contains VMotion configuration information for each host. Note: The Xtravirt Build Method is aimed at ESX 4 installations. ESX 3 can be catered for, but is not covered in this document.

6.1 Demonstration This section is a pre-cursor to the detailed explanation in Section 6.2 and is used to demonstrate the solution over 3 embedded videos in this e-book. To ensure consistency when creating new host configuration files, we wrote a utility to prompt the administrator for key information - hostname, service console IP address and VMotion IP address - see Video 6-1.

Video 6-1: Installer Utility Demonstration

Once a unique host.cfg file and host VMotion file have been created by the utility, the target server can be PXE booted. At the Xtravirt installation menu the hostname of the target buildserver displays. An unattended build process then initiates - see Video 6-2. All common configurations are carried out by various scripts which execute at this time. Once the server has completed configuration it reboots and the ESX Operating System loads. The only configuration task carried out by the scripted installation process at this point is to enable VMotion. VMotion cannot be correctly configured during the previous boot stage as specific modules are not available. Once the server has finished booting, a connection to the host can be made. The configuration performed by the scripted install can be viewed in Video 6-3.

Video 6-2: Installation Demonstration

Note: To enlarge the video, adjust the zoom from the Adobe PDF View menu.

17

6.2 Detailed Explanation and Steps The build mechanism is composed of 3 primary components - see Figure 6-1. xtravirtmethodks.cfg

Contains common configuration data that is pushed to every ESX host that is built

hostx.cfg

Contains specific unique information per host

Post cfg

These files carry out specific configuration tasks

The files are all hosted in a folder structure in the FTP repository. The xtravirtmethodks.cfg file is stored in the root of the esx40 folder for simplicity. The individual hostx.cfg files are stored in the hostcfgs folder, which is a subfolder of esx40. The post configuration files are stored in the postcfgs folder, which is also a subfolder of the esx40 folder. Video 6-3: vMotion Configuration

6.2.1 The xtravirtmethodks.cfg File: Overview Traditionally administrators have created multiple ks.cfg files, one for each host. This creates an administrative overhead and increases the risk of error in each file especially where making multiple updates. The Xtravirt build method utilises a single ks.cfg file to store all common configuration items and control the installation process. Utilising this build method promotes consistency, and in most cases, once scripted customizations are in place, such as vSwitches, port groups, enabling VMotion etc, there is less liklihood of ongoing modification. When adding a new host to the build method the risk of creating an error is reduced and the speed of adding the new hosts into the build is greatly improved.

Figure 6-1: Xtravirt Build Method Folder Architecture

It may be that in your environment the virtualization administrator won’t always be the one adding new hosts. Therefore the more simplistic it is for anyone to add new hosts the easier it is to delegate these tasks. If all that needs adding is a single

18

line with the networking information and hostname there will be a reduced risk of error. Many hosts will often utilize the same gateway, netmask and nameservers. This means that the information required to add an additional host in to the method is often only hostname and IP address. The xtravirtmethodks.cfg file is composed of 4 main parts - see Figure 6-2: %pre

Carries our tasks that are required to make the build process work

Common

Contains kickstart commands to be processed

Host specific kickstart commands

Runs the specific hostx. cfg file

%post scripts

Calls each individual post configuration script file

When the xtravirtmethodks.cfg file is processed, the sections are executed in order.

6.2.2 The xtravirtmethodks.cfg File: %pre Section The %pre section carries out the following tasks: •

Reads the command line syntax that was passed to the installer

•

Locates the value of the name= key that was passed and stores as $name variable

•

Creates the folder /tmp/ xtravirtscripts

•

From the ftp server, downloads $name.cfg, eg: host1.cfg, to /tmp/ xtravirtscripts/host.cfg

•

From the ftp server, downloads $name.vmotion (example, host1. vmotion to /tmp/xtravirtscripts/ vmotion.cfg

•

Downloads the following additional scripts from the ftp server o

vswitches.cfg

o

banners.cfg

o

localaccounts.cfg

o

ntp.cfg

o

rootlogon.cfg

Figure 6-2: Key Sections of the xtravirtmethodks.cfg file

6.2.3 The xtravirtmethodks.cfg File: Common Section The common section carries out the following tasks:

•

Sets the keyboard to UK layout (change this to your own regional setting)

•

Sets the time zone to UTC Europe / London (change this to your own timezone)

•

Accepts the VMware EULA

•

Enables shadow and md5 password handling

•

Tells the installer to reboot when completed

•

Configures the bootloader location as the master boot record

•

Configures root password to xtravirt - change password as required

•

Sets firewall to allow incoming connections

•

Configures the installation source as the ftp server

Once the common section has completed, the %include script host.cfg located at /tmp/xtravirtscripts/host.cfg is executed.

19

Next Steps 1. Open a command prompt window 2. Change directory to E:\ftp_deployment\ esx40\hostcfgs\ 3. Run the following command: cscript.exe newconfig.vbs Figure 6-3: Sequential Execution of the xtravirtmethodks.cfg File

6.2.4 The xtravirtmethodks. cfg File: Host Specific Kickstart Commands

•

The host.cfg file carries out the following tasks - see Figure 6-4:

The contents of each file should be reasonably explanatory.

•

Cleans and partitions the disks in the target server

6.3 Adding a New Host

•

Configures hostname, service console IP address, gateway, nameserver, netmask and disables the creation of the default virtual machine port group

6.2.5 The xtravirtmethodks.cfg File: Individual %post Scripts The post scripts section calls individual scripts in sequence. Each script carries out specific configuration tasks: •

%include /tmp/xtravirtscripts/ vswitches.cfg. Configures virtual switches, portgroups and vlans

•

%include /tmp/xtravirtscripts/ banners.cfg. Configures banners and MOTD

•

%include /tmp/xtravirtscripts/ntp.cfg. Configures ntp settings

•

%include /tmp/xtravirtscripts/ localaccounts.cfg. Creates various local accounts and configures sudo access

•

%include /tmp/xtravirtscripts/ rootlogon.cfg. Enables root access via ssh

%include /tmp/xtravirtscripts/ vmotion.cfg. Creates a file to run after the next reboot to enable VMotion

To add a new host, a new host specific configuration needs to be generated. A visual basic script has been included in the learning materials which can do this automatically. Note: If you wish to use alternative IP addressing to that used in this e-book, edit the E:\ftp_deployment\ esx40\hostcfgs\host_template.cfg, and amend the gateway and nameserver IP addresses. Also modify E:\ftp_deployment\esx40\ xtravirtmethodks.cfg, amending any 192.154.30.2 IP addresses to the IP address of your own WDS/ File server.

Figure 6-4: host.cfg File

4. When prompted, enter the hostname, service console IP address and VMotion IP address

Once complete, simply boot the new ESX host using PXE and select the scripted installation option, providing the hostname. Next Steps 1. PXE boot the host that you wish to build 2. At the PXE menu highlight the ESX4.0 (Xtravirt Method) option, press tab and enter name=”your_hostname”, where your_hostname is the hostname you entered previously. 3. Press Enter

The new host will now run the Xtravirt build method applying the unique information you provided, eg: hostname, service console IP address, VMotion IP and any other customizations. Note: If an incorrect hostname is found then the installation will fail.

20

Appendix A A1 Using DHCP Reservations to Allocate IP Addresses to ESX Hosts DHCP reserved IP addresses are distributed to hosts based on an IP to MAC address relationship. A reservation for a physical server is created in the DHCP scope by providing the MAC address of the network adaptor and the IP address you wish to assign. With ESX we assign the IP address to the service console, so the reservation actually needs to be created using the MAC address of vswif0. It is not possible to specify the MAC address for vswif0 as part of the scripted build process. The MAC address is created by the ESX installer during the installation process. The reservation will need to be created post installation. This introduces a two stage process.

Figure A-1: Using DHCP reservations requires a staged approach to allocating the final IP address

During stage 1, the ESX host boots up and obtains a free IP address on a lease from the DHCP server. The IP address is chosen from the scope range. The server will build using this assigned IP address. Once the server is built, the administrator can logon to the ESX console and obtain the MAC address for vswif0. Note: The ‘ifconfig vswif0’ command can be used to obtain the MAC address

Figure A-2: Obtaining the vswif0 MAC address (00:50:56:41:CC:B8)

21

Once the vswif0 MAC address has been obtained a reservation can be created in the DHCP scope. Once the reservation is created, reboot the ESX host to obtain the allocated IP address.

Figure A-3: Creating a reservation in DHCP

This two stage process may seem long winded. However, it has multiple benefits: •

Centralised control of the hosts IP address, subnet mask, gateway address and DNS address.

•

If a static IP address is allocated through the KS.CFG file, multiple files need to be edited in the console (or alternatively through the GUI) to change it (as well as DNS, gateway and subnet mask information). To change any information with this method, simply update the reservation and reboot the host

•

Centralised recorded information of IP addresses for each ESX host (within the DHCP console)

Note: If this method is used, the host will be built with a name of localhost. A further script could be run to change the name of the host which could be called from the %post section of the KS.CFG file.

22

A2 ESX 4 Sample Code This section contains script examples for common tasks that can be performed during %post section processing.

A2.1 Create a vSwitch Creates a vSwitch (vSwitch1) esxcfg-vswitch –a vSwitch1

A2.2 Delete a vSwitch Deletes a vSwitch (vSwitch1) esxcfg-vswitch –d vSwitch1

A2.3 Create a Port Group Adds a portgroup (called LAB) to an existing vswitch (vSwitch1) esxcfg-vswitch –A LAB vSwitch1

A2.4 Delete a Port Group Deletes a portgroup (called LAB) from an existing vSwitch (vSwitch1) esxcfg-vswitch –D LAB vSwitch1

A2.5 Configure a VLAN ID for a Specific Port Group Configures a VLAN (vlan 101) for a specific portgroup (called LAB) on an existing vSwitch (vSwitch1) esxcfg-vswitch –p LAB -v 101 vSwitch1

A2.6 Remove a VLAN ID for a Specific Port Group on a vSwitch Removes a configured VLAN (vlan 101) for a specific portgroup (called LAB) on an existing vSwitch (vSwitch1) esxcfg-vswitch –p LAB -v 0 vSwitch1

A2.7 Configure a VLAN ID for all Port Groups on a vSwitch Configures a VLAN (vlan 101) for all portgroups on an existing vSwitch (vSwitch1) esxcfg-vswitch –p ALL -v 101 vSwitch1

23

A2.8 Remove a VLAN ID for all Port Groups on a vSwitch Removes a configured VLAN (vlan 101) for all portgroups on an existing vSwitch (vSwitch1) esxcfg-vswitch –p ALL -v 0 vSwitch1

A2.9 Link a Network Adaptor to a vSwitch Links a nic (nic1) to an existing vSwitch (vswitch1) esxcfg-vswitch –L vmnic1 vSwitch1

A2.10 Un-link a Network Adaptor from a vSwitch Un-links a nic (nic1) from an existing vSwitch (vswitch1) esxcfg-vswitch –U vmnic1 vSwitch1

A2.11 Configure a Logon Message (for SSH Connections) Configures a logon message to be displayed for users that connect to the ESX host using a SSH connection Setsshbanner() { touch /etc/ssh/ssh_banner cat >> /etc/ssh/ssh_banner > /etc/ssh/sshd_config > /etc/issue > /etc/motd > /etc/sudoers /etc/ntp.conf echo restrict default kod nomodify notrap noquery nopeer >> /etc/ntp.conf echo server 0.win2k301.xtravirt.lab >> /etc/ntp.conf echo fudge 127.127.1.0 stratum 10 >> /etc/ntp.conf echo driftfile /var/lib/ntp/drift >> /etc/ntp.conf Create the Step-Tickers File echo server 0.win2k301.xtravirt.lab >> /etc/ntp/step-tickers esxcfg-firewall -e ntpClient service ntpd start }

26

Appendix B: Manual WDS\IIS Configuration B1 Creating a Basic WindowsPE Image File 1.

Once the Microsoft Windows AIK toolkit has been installed, click Start -> Programs -> Microsoft Windows AIK -> Windows PE Tools Command Prompt.

2.

At the command prompt enter the following command copype x86 C:\ebook_disk

Figure B-1: Creating a basic Windows PE Image File

3.

Looking in the c:\ebook_disk directory, the .WIM file can be found.

B2 Installing WDS, FTP Components (Manually) The WDS role needs to be installed on to the win2k302 server. This section outlines the process to accomplish this. 1.

Add the Windows Deployment Services Role to the server from Add/Remove programs -> Windows Components

Figure B-2: Installing the WDS Role

2.

When prompted, reboot the server

27

B3 Install IIS and Create an FTP Site 1.

Create a file called iis_components.inf file in the root of the C: drive on the server

2.

Add the following contents to the file [Components] iis_common = ON iis_www = ON iis_www_vdir_scripts = ON iis_inetmgr = ON iis_ftp = ON

3.

Open a command prompt and run the following: Sysocmgr.exe /i:%windir%\inf\sysoc.inf /u:c:\IIS_components.inf

4.

Open the Internet Information Services (IIS) Manager from Administrative Tools

5.

From under the FTP sites folder, stop the default FTP site and delete it.

6. Right-click FTP Sites and select New -> FTP site 7.

Create a new FTP site with the following details: Description: ftp deployment point IP: All Unassigned, port 21 Do not isolate users Path: E:\ftp_deployment Read permissions

8.

Close Internet Information Services (IIS) Manager

B4 Configure WDS Services 1.

Open Windows Deployment Services from Administrative Tools

2.

Expand servers, highlight your server, right-click and select Configure Server

3.

Configure WDS using the following details: Path: E:\remoteinstall Policy: Respond to all (known and unknown) client properties

4.

In the Windows Deployment Services console, right-click Boot Images and add the winpe_basic.wim file, located in the C:\ ebook_disk folder.

Figure B-3: Adding a boot image in to WDS

28 5. Right-click the server and select Properties. From the Advanced tab, ensure the following is enabled Yes, I want to authorize the Windows Deployment Services server in DHCP

B5 Adding Support for ESX 3.5 B5.1 Configuring the Boot Menu From the ESX3.5 media, copy and rename the following files isolinux\vmlinuz – copy to E:\remoteinstall\boot\x86\linux\ vmlinuz-esx35 isolinux\initrd.img – copy to E:\remoteinstall\boot\x86\linux\ initrdesx35.img

In the E:\remoteinstall\boot\x86\pxelinux.cfg folder create a file called default.

Figure B-4: Create and edit the default file

Edit the default file and add the following text: DEFAULT menu.c32 TIMEOUT 100 PROMPT 0 MENU WIDTH 60 MENU MARGIN 10 MENU ROWS 10 MENU TABMSGROW 18 MENU CMDLINEROW 18 MENU ENDROW 24 MENU TIMEOUTROW 20 MENU TITLE Xtravirt Installation Menu LABEL Xtravirt WAIK PE (x86) MENU LABEL Xtravirt WAIK PE (x86) KERNEL pxeboot.0 LABEL ESX35M MENU LABEL ESX3.5 Manual Install KERNEL linux/vmlinuz-esx35 APPEND initrd=linux/initrd-esx35.img

From the Windows Deployment Services console, select the server, right-click and select Properties. From the Boot tab, amend the Default boot program to point to the Boot\x86\pxelinux.0 file.

29

Figure B-5: Configuring the default boot programs in the WDS console

Close the Windows Deployment Services console

B5.2 Creating the ESX 3.5 Distribution Point In the E:\ftp_deployment folder do the following Create a folder called esx35 Copy the entire contents of the ESX35 media in to the E:\ftp_deployment\ esx35 folder

Ensure that you can browse via FTP to the E:\ftp_deployment folder.

Figure B-6: Ensure ftp browsing to the distribution point works fine

30

B5.3 Testing a PXE Boot Installation of ESX 3.5 PXE boot your test virtual machine (press F12 at the BIOS screen to select network boot) At the PXE boot men, select the ESX3.5 Manual GUI Install entry

Figure B-7: Test the PXE boot installation of ESX 3.5

The ESX installation process will start. Follow the installation wizard using the following details when prompted Installation Method: FTP Configure TCP/IP: Use dynamic IP configuration (BOOTP/DHCP) FTP site name: 192.154.30.100 Red Hat directory: esx35/ Follow the installation wizard to install ESX 3.5 on your test server

B6 Adding Support for ESX 4.0 B6.1 Enable ESX 4.0 Boot Menu From the ESX4.0 media, copy and rename the following files: isolinux\vmlinuz – copy to E:\remoteinstall\boot\x86\linux\ vmlinuz-esx40 isolinux\initrd.img – copy to E:\remoteinstall\boot\x86\linux\ initrd-esx40.img Edit the E:\remoteinstall\boot\x86\pxelinux.cfg\default file and add the following: LABEL ESX4M MENU LABEL ESX4.0 Manual Install KERNEL linux/vmlinuz-esx4 APPEND initrd=linux/initrd-esx40.img text mem=512M askmedia

31

B6.2 Creating the ESX 4.0 Distribution Point In the E:\ftp_deployment folder do the following: Create a folder called esx40 Copy the entire contents of the ESX40 media in to the E:\ftp_deployment\esx40 folder

B6.3 Adding Scripted Build Support to ESX 3.5 To add a scripted installation file (ks.cfg) file Create your ks.cfg file Copy the ks.cfg file to the E:\ftp_deployment\esx35\ Add an additional entry in to the pxelinux.cfg\default file LABEL ESX35A

MENU LABEL ESX3.5 Scripted (KS.CFG) KERNEL linux/vmlinuz-esx35 APPEND initrd=linux/initrd-esx35.img esx text ks=ftp://192.154.30.2/esx35/ks.cfg ksdevice=eth0

Note: Ensure your KS.CFG file specifies the URL to the ESX35 installation files.

url --url ftp://192.154.30.4/esx35

B7 Adding Support for ESX 4.0 B7.1 Adding Scripted Build Support to ESX 4.0 To add a scripted installation file (ks.cfg) file Create your ks.cfg file Copy the ks.cfg file to the E:\ftp_deployment\esx40\ks.cfg Add an additional entry in to the pxelinux.cfg\default file

LABEL ESX4A MENU LABEL ESX4.0 Scripted (KS.CFG) KERNEL linux/vmlinuz-esx4 APPEND initrd=linux/initrd-esx40.img text ks=ftp://192.154.30.4/ esx40/ks.cfg mem=512M url=ftp://192.154.30.4/esx40

Note: Ensure the ks.cfg file specifies the URL to the ESX40 installation files. Example: install url ftp://192.154.30.4/esx40