Advertisements

VCDX BrownBag #6 – Rapid Provisioning Revision

On the 11th May, we had our VCDX brownbag on Rapid provisioning. now those of you who checked in will know we has some technical issues with the lab, and I had issues with my Microphone, my Skype is playing up, but ,my issues are not pertinent to this discussion so without further ado, lets run thought rapid provisioning 3.5 style.

First the video link to the session

VCDX Brown Bag #8 – Rapid Provisioning from ProfessionalVMware on Vimeo.

Learning notes

Section 8 – Rapid Provisioning

ESX Server Scripted Installation

Knowledge

Explain the usage of the Scripted Installation wizard

A Scripted Installation helps minimize the administrative effort required to install and configure a group of VMware ESX servers. Remember that you should always consider the time it takes to create a unattended installation against the benefits of fast deployment and more importantly an error free configuration (With a scripted installation common errors like the misnaming of vSwitches is mitigated). A typical environment where an unattended installation is useful is a large enterprise where you have a large number of similar configurations, or a lab environment where hosts are built up and torn down with monotonous regularity.
VMware provide a wizard to help in the creation of a KS.CFG file (this is the name of the file used to pass the configuration steps to the installer) this wizard can be reached via the web interface once there select a installation script wizard in the right pane.

Configuring ESX Server for Scripted Installations

To support scripted installations, you will need to configure your ESX Server. To set up the server for scripted installations you will need to complete the following steps.

First enable scripted installation on the installed ESX 3.5 server

Log in to the ESX Server 3.5 service console as root. then open the file shown below in a text editor such as vi or nano.

/usr/lib/vmware/webAccess/tomcat/apache-tomcat-5.5.26/webapps/ui/WEB-INF/struts-config.xml

Once open locate the scripted section. (with /scripted) and place a comment on the line reading:

<action path=”/scriptedInstall”
type=”org.apache.struts.actions.ForwardAction”
parameter=”/WEB-INF/jsp/scriptedInstall/disabled.jsp” />

and then un-comment the following lines:

<!–
<action path=”/scriptedInstall”
type=”com.vmware.webcenter.scripted.ProcessAction”>
<forward name=”scriptedInstall.form1″
path=”/WEB-INF/jsp/scriptedInstall/form1.jsp” />
<forward name=”scriptedInstall.form2″
path=”/WEB-INF/jsp/scriptedInstall/form2.jsp” />
<forward name=”scriptedInstall.form3″
path=”/WEB-INF/jsp/scriptedInstall/form3.jsp” />
<forward name=”scriptedInstall.form4″
path=”/WEB-INF/jsp/scriptedInstall/form4.jsp” />
<forward name=”scriptedInstall.form5″
path=”/WEB-INF/jsp/scriptedInstall/form5.jsp” />
<forward name=”scriptedInstall.form6″
path=”/WEB-INF/jsp/scriptedInstall/form6.jsp” />
<forward name=”scriptedInstall.form7″
path=”/WEB-INF/jsp/scriptedInstall/form7.jsp” />
3</action>
–>

Save and close the file.  To actually comment and un-comment you need to either add or remove the following tags from the desired sections:

<!- – and ends in – – >

Finally type service

vmware-webAccess restart

Once you have configured the host you need to point your favourite web browser at the host, you will be rewarded with the following:

login screen

Click on the ringed section, this will load the Scripted Installer Wizard:

script1

Here I have decided to configure a KS.CFG for CD-ROM installation, once you have filled in your details, by setting your TimeZone and Root Password, click Next:

EULA-Accept

Next “Read and accept the EULA,  click next:

diskselection

Choose your disk layout and click next:

licesnseServerSelection

Enter your License server details and port number, Click next

download

Click the Download Kickstart File to download your local machine and open it in something like Write.exe if on a windows machine or vi, nano, emac’s or any of your favourite text editors that are able to read UNIX aware files.

Describe the various methods of automated deployment

VMware support several methods of installation these are:

  • CD Rom

This is the default installation method,  when used with a scripted installation the KS.CFG script is stored on the virtual floppy drive.

  • HTTP/FTP

The Second method is to boot a server from CD off a PXE boot device and define a FTP server for the Installation files and a HTTP server for the configuration files

  • NFS

The final method is to define a NFS share as network source for your installations files.

Define the directives contained in the installation script

At first look this seem as little confusing what the hell does “directives” mean, well do not be afraid, it simply means that an KS.CFG installation scripts should contain a couple of sections these are I will explain what these mean later:

  • Command
  • %packages
  • %pre
  • %post
  • %vmlicense_text

More later 😀

Skills and Abilities

Set up hardware and various connections
  • Boot from SAN

So what is Boot from SAN?

simply put it is the ability to boot a server from a remote disk situated on a Storage Area Network resource,

  • Use boot from SAN:
    If you do not want to handle maintenance of local storage.
    If you need easy cloning of service consoles (ESX Server 3 only).
    In diskless hardware configurations, such as on some blade systems.
  • Do not use boot from SAN:
    If you are using Microsoft Cluster Service.
    If I/O contention might occur between the service console and VMkernel (ESX
    Server 3 only).

How does it work?

When a Server is set up for Boot from SAN, the boot image is not stored locally on the ESX Host but is instead on a LUN on the Shared storage.

To enable your ESX Server system to boot from a SAN, the following tasks need to be carried out:

Firstly, check that your environment meets the general requirements. See “General ESX
Server SAN Requirements” on page 50. of the SAN Configuration Guide

Benefits of Boot from SAN

In a boot from SAN environment, the operating system is installed on one or more LUNs in the SAN array. The servers are informed about the boot image location. When the servers are started, they boot from the LUNs on the SAN array.

  • Booting from a SAN provides numerous benefits, including:
  • Cheaper servers – Servers can be more dense and run cooler without internal storage.
  • Easier server replacement – You can replace servers and have the new server point to the old boot location.
  • Less wasted space.
  • Easier backup processes – The system boot images in the SAN can be backed up as part of the overall SAN backup procedures.
  • Improved management – Creating and managing the operating system image is easier and more efficient.

Preparation for Boot from SAN

In addition to the general ESX Server with SAN configuration tasks, complete the following tasks to enable your ESX Server host to boot from SAN.

To enable boot from SAN

  1. Ensure that the configuration settings meet the basic boot from SAN requirements.
  2. Prepare the hardware elements. This includes your HBA, network devices, and storage system. Refer to the product documentation for each device
  3. Configure LUN masking on your SAN. This ensures that each ESX Server host has a dedicated LUN for the boot partitions. The boot LUN must be dedicated to a single server.
  4. Choose the location for the diagnostic partition.  Diagnostic partitions can be put on the same LUN as the boot partition. Core dumps are stored in diagnostic partitions.
    The rest of this section lists the tasks you need to complete before you can successfully boot your ESX Server machine from SAN.

LUN Masking in Boot from SAN mode

Proper LUN masking is critical in boot from SAN mode.

  • Each server can see only its own boot LUN, not the boot LUNs of other servers.
  • Multiple servers can share a diagnostic partition. You can use LUN masking to achieve this. See “Sharing Diagnostic Partitions” on page 104.

Preparing the SAN

This section lists the steps for preparing the SAN storage array for boot from SAN.

To prepare the SAN

Connect the FC and Ethernet cables, referring to any cabling guide that applies to your setup.  Check the FC switch wiring, if there is any.

Configure the storage array refer to your Storage Configuration Guides.

  • From the SAN storage array, make the ESX Server host visible to the SAN. This
    is often referred to as creating an object.
  • From the SAN storage array, set up the ESX Server host to have the WWPNs
    of the host’s FC adapters as port names or node names.
  • Create LUNs.
  • Assign LUNs.
  • Record the IP addresses of the FC switches and storage arrays.
  • Record the WWPN for each SP and host adapter involved.

Boot your ESX Server system from the ESX Server installation CD. See the Installation Guide.

CAUTION The QLogic BIOS uses a search list of paths (wwpn:lun) to locate a boot image. If one of the wwpn:lun paths is associated with a passive path (as could be the case with CLARiiON or IBM TotalStorage DS 4000 systems), the BIOS stays with the passive path and does not locate an active path. If you are booting your ESX Server system from a SAN LUN, the boot fails while the host tries to access the passive path.

CAUTION If you use scripted installation to install ESX Server in boot from SAN mode, you need to take special steps to avoid unintended data loss. See VMware knowledge base article 1540.

Settiing up the FC HBA for Boot From SAN

In preparation for configuring your SAN and setting up your ESX Server system to use
SAN storage, review the following requirements and recommendations(procedure taken from the SAN Configuration Guide):

To Configure a QLogic HBA BIOS to boot ESX Server

The first thing to do when configuring a QLogic HBA to boot an ESX Server from SAN LUN is to configure the QLogic HBA BIOS. To do this follow the procedure laid down below:

Enter the BIOS Fast!UTIL configuration utility, to do this:

Cold boot your server.

When the QLogic device appears on the screen press Ctrl-Q.

  • If you have only one host bus adapter (HBA), the Fast!UTIL Options page appears. .
  • If you have more than one HBA, select the HBA manually:

select Configuration Settings from the Fast!UTIL Options page, and press Enter.

Once in the Configuration Settings page, select Host Adapter Settings and press Enter.

Set the BIOS to search for SCSI devices:

  • In the Host Adapter Settings page, select Host Adapter BIOS.
  • Press Enter to toggle the value to Enabled.
  • Press Esc to exit.

Enabling the Selectable Boot

To enable the selectable boot:

Choose Selectable Boot Settings and press Enter.

In the Selectable Boot Settings page, choose Selectable Boot.

Press Enter to toggle the value to Enabled.

Selecting the Boot LUN

If you are using an active/passive storage array, the selected SP(Storage Processor) must be on the preferred (active) path to the boot LUN. The target IDs are created by the BIOS and might change with each reboot.

To select the boot LUN

Use the cursor keys to select the first entry in the list of storage processors.

Press Enter to open the Select Fibre Channel Device page.

Use the cursor keys to select the chosen SP and press Enter.

  • If the SP has only one LUN attached, it is selected as the boot LUN, else;
  • If the SP has more than one LUN attached, the Select LUN page opens. Use the arrow keys to position to the selected LUN and press Enter.
    If any remaining storage processors show in the list, position to those entries and press C to clear the data.

Press Esc twice to exit.
Press Enter to save the setting.

Setting Up Your System to Boot from CD-ROM First

Because the VMware installation CD is in the CD‐ROM drive, set up your system to boot from CD‐ROM first. To achieve this, change the system boot sequence in your system BIOS setup.

Configuring an Emulex FC HBA for Boot from SAN

Configuring the Emulex HBA BIOS to boot ESX Server from SAN includes the following tasks:

  • To enable the BootBIOS prompt
  • To enable the BIOS

To enable the BootBIOS prompt

From the ESX Server service console or a Linux command prompt, run lputil.

Select <3> Firmware Maintenance.

Select an adapter.

Select <6> Boot BIOS Maintenance.

Select <1> Enable Boot BIOS.

To enable the BIOS

Reboot the ESX Server machine.

As the Machine undergoes the boot process Press <ALT+E> as when the Emulex device shows on the screen.

  • Select an adapter (with BIOS support).
  • Select <2> Configure Adapterʹs Parameters.
  • Select <1> Enable or Disable BIOS.
  • Select <1> to enable BIOS.
  • Select <x> to exit and <N> to return to the main menu.

From the Emulex main menu:

  • Select the same adapter.
  • Select <1> Configure Boot Devices.
  • Select the location for the Boot Entry.
  • Enter the two‐digit boot device.
  • Enter the two‐digit (HEX) starting LUN (for example, 08).
  • Select the boot LUN.
  • Select <1> WWPN. (Boot this device using WWPN, not DID).
  • Select <x> to exit and <Y> to reboot.

Boot into the system BIOS and move Emulex first in the boot controller sequence.

Reboot and install on a SAN LUN.

your Host server is now configured to install to a SAN Device.

Create an install script and verify the following sections

Remember that script we created via the “Scripted install Wizard” well here it is below

Auto-Generated Scripted Install Configuration file.

# This file is used for VMware ESX Server Scripted Install Deployment
# Installation Method
cdrom
# root Password
rootpw –iscrypted $1$Eg2RGTxl$NcwG6MFFZkx0fTu/4vtIJ1
# Authconfig
auth –enableshadow –enablemd5
# BootLoader ( The user has to use grub by default )
bootloader –location=mbr
# Timezone timezone
Europe/London
# X windowing System
skipx

# Install or Upgrade
install
# Text Mode
text
# Network install type
network –bootproto dhcp –addvmportgroup=0 –vlanid=0
# Language
lang en_UK
# Langauge Support
langsupport –default en_UK
# Keyboard keyboard
uk
# Mouse
mouse none
# Reboot after install ?
eboot
# Firewall settings
firewall –disabled
# Clear Partitions
clearpart –all –initlabel –drives=sda
#Partitioning
part /boot –fstype ext3 –size 250 –ondisk sda
part / –fstype ext3 –size 5000 –ondisk sda
part swap –size 1600 –ondisk sda
part None –fstype vmfs3 –size 10000 –ondisk sda
part None –fstype vmkcore –size 110 –ondisk sda
art /var –fstype ext3 –size 2500 –ondisk sda
part /opt –fstype ext3 –size 2500 –ondisk sda < sda –ondisk 2500 –size ext3 –fstype home>
# VMware Specific Commands
vmaccepteula vmlicense –mode=server –server=27001@<enter license server> –edition=esxFull
%packages
@base
%post
%vmlicense_text

Now the above is the default script and will need some modification to be truly useful, but first lets explain what the sections actually mean.

  • Command
    Although this section is not physically defined in the file, it contains the installer specific commands, like the desired timezone setting and the keyboard selection.
  • %packages
    place in this section any additional RPM packages you wish to install, it usually only contains @base.
  • %pre
    The special marker “%pre” identifies a section that should be executed before the installer runs, this section must come after the commands section. The thing that makes this work is that anything in it can be bash script. So here you would define Storage Drivers etc.
  • %post
    The post marker identifies all the commands or scripts to be run after the installer has completed its work, so here would be things like vSwitch configuration and NTP settings.
  • %vmlicense_text
    This section contains the license file for an ESX server that is configured for host based licensing.
Configure Service Console components of an ESX server

As already mentioned the default KS.CFG file that is created via the “installation wizard” is very basic.  To make it useful we need to configure the %post sections now the blue print specifically points out knowledge of the following, but it is my belief that this will not be enough for the exam:

  • Network Time Protocol (NTP)
#################
# Configure NTP #
#################

# Add servers to step-tickers
echo "ntp.unsw.edu.au" > /etc/ntp/step-tickers
echo "ntp2.unsw.edu.au" >> /etc/ntp/step-tickers

echo "restrict 127.0.0.1" > /etc/ntp.conf
echo "restrict default kod nomodify notrap" >> /etc/ntp.conf
echo "server ntp.yourtimeserver.com" >> /etc/ntp.conf
echo "server ntp2.yourtimeserver.com" >> /etc/ntp.conf
echo "driftfile /var/lib/ntp/drift" >> /etc/ntp.conf

chkconfig ntpd on
service ntpd restart
hwclock --systohc
  • DNS
#################
# Configure DNS #
#################

echo "search myDNS.PlanetVM.NET" > /etc/resolv.conf
echo "nameserver 123.123.123.1" >> /etc/resolv.conf
echo "nameserver 123.123.123.2" >> /etc/resolv.conf
  • SNMP

##################
#Configure SNMP

##################

echo ” Configuring SNMP”

echo “defcommunity 1” >> /usr/share/snmp/snmp.conf

echo “rocommunity 1” >> /usr/share/snmp/snmpd.conf

All three of the above examples are on the whole simple redirections, and do not show the true power a scripted install; now remember that the Current Enterprise Admin exam is based on VI3, therefore no vDistibruted Switches, but you can create your Standard switching environment via the KS.CFG file, remember VCDX brownbag #1 where we discussed virtual networking and introduced the CLI commands for creating vSwitches, well here it is in action.

#############################

#Configure ESX Networking

#############################

/usr/sbin/esxcfg-vswitch -a vSwitch1

/usr/sbin/esxcfg-vswitch -a vSwitch2

/usr/sbin/esxcfg-vswitch -L vmnic1 vSwitch1

/usr/sbin/esxcfg-vswitch -L vmnic3 vSwitch1

/usr/sbin/esxcfg-vswitch -L vmnic2 vSwitch0

/usr/sbin/esxcfg-vswitch -L vmnic4 vSwitch1

/usr/sbin/esxcfg-vswitch -L vmnic5 vSwitch2

/usr/sbin/esxcfg-vswitch -A “Development” vSwitch1

/usr/sbin/esxcfg-vswitch -A “DMZ” vSwitch1

/usr/sbin/esxcfg-vswitch -A “Production” vSwitch1

/usr/sbin/esxcfg-vswitch -A “VMotion” vSwitch2

/usr/sbin/esxcfg-vswitch -p “Development” -v 7 vSwitch1

/usr/sbin/esxcfg-vswitch -p “DMZ” -v 2 vSwitch1

As you can see we have used the “esxcfg-vswitch –a” to create additional 2 vSwitches, wis is followed by “esxcfg-vswitch –L” to add vmnics to those switches and an additional vmnic to vSwitch0 thereby providing resilience. next we create the required portgroups using the “–A” option and lastly assigned those portgroups “–p” with a vlanid using “-v”

#############################

#Configure NIC duplex/speed settings

#############################

/usr/sbin/esxcfg-nics -s 1000 -d full vmnic0

/usr/sbin/esxcfg-nics -s 1000 -d full vmnic1

/usr/sbin/esxcfg-nics -s 1000 -d full vmnic2

/usr/sbin/esxcfg-nics -s 1000 -d full vmnic3

/usr/sbin/esxcfg-nics -s 1000 -d full vmnic4

/usr/sbin/esxcfg-nics -s 1000 -d full vmnic5

This next section sets the NICs speed and duplex settings,  it is self explanatory.

#############################

#Configure Teaming Policy

#############################

vimsh -n -e “/hostsvc/net/vswitch_setpolicy –nicteaming-policy loadbalance_ip vSwitch1”

This next section is a little more complicated as it requires the use of vimsh to set the teaming policy, but basically it sets the default teamin policy to loadbalance using IP hash, this is because the default setting is “failover” only.  For a better overview of VMware MetaShell see here

There are plenty more options that can be added and I have found Leo’s Ramblings to be an excellent site for this subject.

Install supported third party agents according to the design plan

the KS.CFG fully supports the installation of 3rd party agents if their instalation routine can be scripted.below is an example of the installation of the Dell Open Manage agents

####################################################

# Dell OM Agent
####################################################

mkdir -p /root/OM

#Download OM.tar.gz

esxcfg-firewall –allowOutgoing

lwp-download http://webserver/OM/OM.tar.gz /root/OM/.

esxcfg-firewall –blockOutgoing

cd /root/OM

tar -zxf OM.tar.gz

chmod a+x *.*

./linux/supportscripts/srvadmin-install.sh -x

#./linux/supportscripts/srvadmin-services.sh start

/usr/sbin/esxcfg-firewall -o 1311,tcp,in,OpenManageRequest

This is quite a complicated section, the first command creates the /root/OM directory, the –p option on the command forces the command to create the /root directory if it does not already exist.

The second section configures the firewall to allow outgoing and downloads the tar file for OpenManage from the stated webserver address, the hole in the firewall is then closed again.

We then change to the /root/OM direcory and extract the package, by using the tar comamnd with the –zxf options, these relate to

  • -z: unzip
  • -x  extract
  • -f  file

The resulting files are modifed with the execute option and then the install script is executed,

The final line is allowing the ports for OpenManage to traverse the Firewall.

Tools

· VI client

· CLI

Useful Links

VMware SAN Configuration guide

VMware Virtual Machine Backup Guide

VMware ESX Server 3 Installation Guide

Editing the Kickstart Configurations File

The Mother of all ESX Kickstart scripts part 1

The Mother of all ESX Kickstart scripts part 2

The Mother of all ESX Kickstart scripts part 3

Advertisements

1 ping

  1. […] This post was mentioned on Twitter by tom_howarth and PlanetVM Net, PlanetVM Net. PlanetVM Net said: Updated a blog post on PlanetVM.NET: ( https://planetvm.net/blog/?p=1545 ) […]

Comments have been disabled.

%d bloggers like this: