Translate

Total Pageviews

My YouTube Channel

Friday, 27 July 2012

Deploying ESXi 5.0 using the Scripted Install feature

Purpose

This article explains how to setup Scripted Install, and some of the features that might be useful to you when getting started. This is not a comprehensive guide, but should be used as a reference when setting up your Scripted Install environment. For more detailed information on setting up Scripted Install, see the ESXi and vCenter Server Installation and Setup guide.

Resolution

The scripted install feature of ESXi 5.0 provides an efficient way to deploy multiple ESXi hosts. You can quickly deploy ESXi hosts using unattended installations with Scripted Install. The installation script ( ks.cfg) contains settings for your ESXi hosts that can be modified to suit the needs of your environment. You can apply the script to all hosts that you want to have a similar configuration. This allows you to perform swift installations, in a shorter amount of time than it would by performing a manual installation. In addition, this ensures that all hosts have similar configurations and are built to the standard you want.

Differences of Scripted Install between ESXi 4.x and 5.x

If you have used Scripted Install in the past with ESXi 4.x, before performing a Scripted Install with ESXi 5.0, you should be familiar with the differences between ESXi 4.x and ESXi 5.0 scripted installation commands. These are the differences to note:
  • In ESXi 5.0, because the installation image is loaded directly into the host RAM when the host boots, there is no need to include the location of the installation media in the installation script.
  • ESXi 5.0 supports scripted upgrades in addition to scripted installation. In ESXi 4.x, you could only do fresh installations.
  • Some commands have been deprecated or changed:
    • Deprecated commands: auth/authconfig, bootloader, firewall, firewallport, timezone, virtualdisk, zerombr, %packages
    • Changed commands: autopart (replaced by install, upgrade, installorupgrade),esxlocation, serialnum / vmserialnum

Prerequisites

Performing a Scripted Install with ESXi 5.0 requires:
  1. Creating a script ( ks.cfg) using the supported commands.
  2. Editing the installation script as needed to change settings that are unique for each host.
  3. Running the scripted installation process by either specifying boot options, or automatically booting using PXE boot.
The installation script ( ks.cfg) can reside in any of these locations:
  • FTP
  • HTTP/HTTPS
  • NFS Share
  • USB flash drive
  • CD/DVD device

How to specify booting off the customized ks.cfg file

You can install ESXi 5.0 on multiple machines using a single script or a separate script for each machine. You can start the installation script by two different methods:
  • Boot up interactively by pressing Shift+O during the boot loader. Enter commands to locate the ks.cfg file.

    Example: ks=<location of installation script> <boot command line options>
  • To perform a more automated installation, you can pass options through the kernelopt line of the boot.cfg file for a PXE boot installation. Setting up a PXE boot server is beyond the scope of this article, and is unique in every environment. For more information on setting up a PXE boot, see the ESXi and vCenter Server Installation and Setupguide.
Note: A ks= option must be given to specify the location of the installation script ( ks.cfg ) file. If ks= is omitted, the text installer proceeds as if it were a normal installation.
Options for the ks= command
Boot Option
Description
BOOTIF=<MAC address>
Tries to use a network adapter device when looking for an installation script and installation media.
gateway=<ip address>
Sets this network gateway as the default gateway
ip=<ip address>
Sets up a static IP address to be used for downloading the installation script and the installation media.
ks=cdrom:/<path\>
Performs a scripted installation with the script at path, which resides on the CD in the CD-ROM drive.
ks=file://<path>
Performs a scripted installation with the script at path.
ks=protocol://<serverpath>
Performs a scripted installation with a script located on the network at the given URL. Protocol can be HTTP, HTTPS, FTP, or NFS.
ks=usb:</path>
Performs a scripted install, accessing the script from an attached USB drive. Searches for a file named ks.cfg.
nameserver=<ip address>
Specifies a domain name server
netdevice=<device>
Use network adapter device (MAC or vmnicN)
netmask=<subnet mask>
Specifies subnet mask for the network interface
vlanid=<vlanid>
Configure the network card to be on the specified VLAN

Example: Booting off an NFS share uses a command like this:
ks=nfs://192.168.0.101/FS2/isos/esxi-B.cfg nameserver=192.168.0.57 ip=192.168.0.3 netmask=255.255.255.0 gateway=192.168.0.254

Creating the ks.cfg file

In order to customize an ESXi installation a ks.cfg file must be created before performing the above boot process. The default installation script ks.cfg is located in the initial RAM disk at /etc/vmware/weasel/ks.cfg.
You can specify the location of the ks.cfg in the installation script with the boot optionks=file://etc/vmware/weasel/ks.cfg if you do not wish to perform any customizations.
Note: When you install ESXi using ks.cfg, the default root password is set to mypassword.
Example: This is what the ks.cfg file looks like in /etc/vmware/weasel:
#
# Sample scripted installation file
#
# Accept the VMware End User License Agreement
vmaccepteula
# Set the root password for the DCUI and Tech Support Mode
rootpw mypassword
# The install media is in the CD-ROM drive
install --firstdisk --overwritevmfs
# Set the network to DHCP on the first network adapater
network --bootproto=dhcp --device=vmnic0
# A sample post-install script
%post --interpreter=python --ignorefailure=true
import time
stampFile = open('/finished.stamp', mode='w')
stampFile.write( time.asctime() )
Beyond this, you can further customize the script to suit your environment. The following tables show what commands you can use to customize your scripts. When using these tables, be aware that:
  • An argument is defined as any word which comes after a command, and usually (although not always) begins with two dashes.
  • A string is defined as any value which is assigned to a command or argument. Strings can be double-quoted, single-quoted, or contain no quotes providing they have no white space characters.
  • The ks.cfg script itself contains a non-ordered list of commands, most of which take additional arguments.
  • Commands can be either single- or multi-line, where multi-line commands always begin with the % character and finish either at the end of the script or when a separate multi-line command begins.
  • Comments can be added inside the script with the # character, providing it is outside of a string. All characters after the # are ignored.
You can use these commands in your ks.cfg file:
Clearing partitions
Command
Function
clearpart (optional)
Clear any existing partitions on the disk. Requires installcommand to be specified.
--drives=
Remove partitions on a specified drive.
--alldrives
Ignore the “--drives=" requirement and allows clearing partitions on every drive.
--ignoredrives=
Remove partitions on all drives except those specified. Required unless the --drives= or --alldrives flags are specified.
Permit overwriting of vmfs partitions on the specified drives. By default, overwrite vmfs partitions is not allowed.
- -overwritevmfs
--firstdisk(=<disk-type1>,[<disk-type2>, ...])
Partitions the first eligible disk found. The order of the eligible disks is set to:
1 locally attached storage (local)
2 network storage (remote)
3 usb disks (usb)
You can change the ordering of the disks by using a comma separated list appended to the argument.

Examples:
  • clearpart --firstdisk --overwritevmfs
  • clearpart --drives=mpx.vmhba1:C0:T1:L0 --overwritevmfs
  • clearpart --drives=vml.0000000000766d686261313a313a30 –overwritevmfs
Creating partitions
Command
Function
part or partition (optional)
Creates an additional VMFS datastore on the system. Only one datastore per disk can be created. Cannot be used on the same disk as the install command.
<datastore name>
Specifies where the partition is to be mounted
--ondisk= or --ondrive=
Specifies the disk or drive where the partition is created.
--onfirstdisk
Partitions the first eligible disk found. The order of the eligible disks are set to:
(=<disk-type1>,[<disk-type2>, ...])
1 locally attached storage (local)
2 network storage (remote)
3 usb disks (usb)
You can change the ordering of the disks by using a comma separated list appended to the argument.

Examples:
  • partition –ondisk=mpx.vmhba1:C0:T1:L0 datastore2
  • partition datastore2 --ondisk=mpx.vmhba1:C0:T2:L0
  • part datastore2 --firstdisk=ST3120814A,mptsas,local
Installation options
 
Command
Function
install
Specifies that this is a fresh installation.
Replaces the deprecated autopart command used for ESXi 4.1 scripted installations.
One of the commands install, upgrade, or installorupgrade is required to determine which disk to install or upgrade ESXi on.
--disk= or --drive=
Specifies the disk to partition.
--firstdisk=
Partitions the first eligible disk found. The order of the eligible disks is set to:
disk-type1,
1 locally attached storage (local)
[disk-type2,...]
2 network storage (remote)
3 usb disks (usb)
You can change the ordering of the disks by using a comma separated list appended to the argument
--overwritevmfs
Required to overwrite any existing VMFS datastore on the disk before installation.
--preservevmfs
Preserves an existing VMFS datastore on the disk during installation.
--novmfsondisk
Prevents a VMFS partition from being created on this disk. Must be used with --overwritevmfs if a VMFS partition already exists on the disk.

Examples:
  • install --firstdisk --overwritevmfs
  • install --overwritevmfs –-novmfsondisk
Upgrade options
Command
Function
upgrade
Specifies that this is a upgrade.
Replaces the deprecated autopart command used for ESXi 4.1 scripted installations.
One of the commands install, upgrade, or installorupgrade is required to determine which disk to install or upgrade ESXi on.
--disk= or --drive=
Specifies the disk to partition.
--firstdisk=
Partitions the first eligible disk found. The order of the eligible disks is set to:
disk-type1,
1 locally attached storage (local)
[disk-type2,...]
2 network storage (remote)
3 usb disks (usb)
You can change the ordering of the disks by using a comma separated list appended to the argument
--deletecosvmdk
If the system is being upgraded from ESX, remove the directory containing the old Console VMDK file,cos.vmdk, to reclaim unused space in the VMFS datastore.

Examples:
  • upgrade --firstdisk
  • upgrade --firstdisk –deletecosvmdk
Install or Upgrade options
Command
Function
installorupgrade
One of the commands install, upgrade, or installorupgrade is required to determine which disk to install or upgrade ESXi on.
--disk= or --drive=
Specifies the disk to partition.
--firstdisk=
Partitions the first eligible disk found. The order of the eligible disks is set to:
disk-type1,
1 locally attached storage (local)
[disk-type2,...]
2 network storage (remote)
3 usb disks (usb)
You can change the ordering of the disks by using a comma separated list appended to the argument
--overwritevmfs
Install ESXi if a VMFS partition exists on the disk, but there is no ESX or ESXi installation.
Unless this option is present, the installer fails if a VMFS partition exists on the disk, but there is no ESX or ESXi installation

Example:
  • installorupgrade --firstdisk –overwritevmfs
Miscellaneous options
Command
Function
keyboard
Set the keyboard type for the system to one of the following: Default, French, German, Japanese, Russian.
dryrun (optional)
Parse and check the kickstart file, but do not actually do the install.
accepteula or vmaccepteula (required)
Accepts the VMware License Agreement (EULA).
reboot
Reboot the machine after the scripted installation is finished.
--noeject
Do not eject the CD after installation.
rootpw (optional)
Set the root (admin) password for the system.
--iscrypted
Specifies that the password is already encrypted.
paranoid (optional)
Causes any warning messages to interrupt the installation. If you omit this command, warning messages are logged.

Examples:
  • vmaccepteula
  • rootpw vmware
  • keyboard German
Network options
Command
Function
network (optional)
Specify a network address for the system.
--bootproto=
Specify whether to obtain the network settings via DHCP or set it manually.
[dhcp|static]
--device=
Either the MAC address of the network card or the device name, of the form vmnicN. This option refers to "uplink" device for the virtual switch.
--ip=
Set the IP address for the system. This is used with the static bootproto option and is required if the static option is specified and ignored otherwise. This should be in the form xxx.xxx.xxx.xxx.
--gateway=
Specify the network gateway. Should be in the formxxx.xxx.xxx.xxx. Used with the static bootproto option. If no option is specified, warn in the log file and continue with no gateway setting.
-- nameserver=
Specify up to two nameservers. Used with thestatic bootproto option.Should be in the formxxx.xxx.xxx.xxx,[xxx.xxx.xxx.xxx].
--nodns
Not used. This is the same as not specifying --nameserver= or not appending any arguments to it.
--netmask=
Netmask for the specified system. This should default to the proper netmask for the given type of ip address. Should be in the form “255.xxx.xxx.xxx". Used with the static bootproto option.
--hostname=
Specifies the hostname for the system.
--vlanid=
Specifies which VLAN the system is on. Used with either dhcp or static bootproto option. Should be an integer between 1 and 4094.
--addvmportgroup=
Specifies whether or not to add the VM Networkport group which is used by virtual machines. The default value is 1.
(0|1)

Examples:
  • network –bootproto=dhcp --device=vmnic0 --addvmportgroup=0
     
  • network --bootproto=static --device=vmnic0 --ip=123.123.123.123 --netmask=255.255.252.0 --gateway=123.123.123.120 --nameserver=123.123.123.4
     
Pre-, post-, and first boot script options
Command
Function
%pre
Specifies a script to be executed before the kickstart configuration is to be evaluated. For example, it can be used to generate files to be included by the kickstart file. Requires the -unsupportedargument.
--interpreter= [python|busybox]
The script interpreter to use, defaults to busybox.
--unsupported (required)
Required argument, to force an acknowledgement that the command is unsupported.
%post
Execute the specified script after installation has been completed. If multiple %post sections are specified, they are executed in the order they are found in the kickstart file..
--interpreter= [python|busybox]
The script interpreter to use, defaults to busybox.
--unsupported (required)
Required argument, to force an acknowledgement that the command is unsupported.
--timeout=secs
Set a timeout for executing the script. If the script has not finished when the timeout expires, the script is forcefully terminated.
--ignorefailure=
If true, then the installation is considered a success even if the%post script terminated with an error.
[true|false]
%firstboot
Causes an init script to be created. The init script executes the commands specified in the %firstboot section during the first boot only; it has no effect on subsequent boots. If multiple%firstboot sections are specified and their level is the same, they are executed in the order they are found in the kickstart file.
--interpreter= [python|busybox]
The script interpreter to use, defaults to busybox.
--unsupported (required)
Required argument, to force an acknowledgement that the command is unsupported.
--level=level
Determines the order in which the script is executed at boot. Care should be taken to set the level high enough so that other needed init scripts (such as loading drivers) can run first. Defaults to 999.
%include OR include
Specify an additional kickstart file to parse. This command is treated similarly to a multi-line command, but takes only one argument.
<filename>
 
 
Many of these commands you may not need to use, but are useful when you need to specifically customize certain options on your ESXi hosts. The Scripted Install feature of ESXi 5.0 is an advanced installation, and requires certain configuration in order for it to perform properly.
With the above options and the example ks.cfg file, you can start customizing your own ESXi 5.0 host builds. For more detailed information regarding setting up a Scripted Install and doing PXE Boot installations, see the ESXi and vCenter Server Installation and Setup guide.
Source of this Info:-

Create a bootable VMware ESXi 5 USB stick in Windows and perform a scripted installation

Formatting a USB Flash Drive to Boot the ESXi 5.0 Installation or Upgrade

Details

You can format a USB flash drive to boot the ESXi 5.0 installation or upgrade.

Solution

This procedure requires the ESXi 5.0 ISO image VMware-VMvisor-Installer-5.0.0- XXXXXX.x86_64.iso, including the file isolinux.cfg,where XXXXXX is the build number of the installer ISO image. You can download the ESXi 5.0 ISO image from the VMware Web site.
 
These instructions assume that you are performing the procedure on a Linux machine and that the USB flash drive is detected as /dev/sdb.

Note: The ks file containing the installation script cannot be located on the same USB flash drive that you are using to boot the installation or upgrade.
  1. Attach the USB flash drive to a Linux machine. 
  2. Create a partition table.
    /sbin/fdisk /dev/sdb
    1. Type d to delete partitions until they are all deleted.
    2. Type n to create primary partition 1 that extends over the entire disk.
    3. Type t to set the type to an appropriate setting for the FAT32 file system, such as c.
    4. Type a to set the active flag on partition 1.
    5. Type p to print the partition table.
      The result should be similar to the following text:
      Disk /dev/sdb: 2004 MB, 2004877312 bytes
      255 heads, 63 sectors/track, 243 cylinders
      Units = cylinders of 16065 * 512 = 8225280 bytes
      Device    Boot  Start   End   Blocks    Id   System
      /dev/sdb1  *    1       243   1951866   c    W95 FAT32 (LBA)
    6. Type w to write the partition table and quit. 
  3. Format the USB flash drive with the Fat32 file system./sbin/mkfs.vfat -F 32 -n USB /dev/sdb1 
  4. Run the following commands./path_to_syslinux-3.86_directory/syslinux-3.86/bin/syslinux /dev/sdb1
    cat /path_to_syslinux-3.86_directory/syslinux-3.86/usr/share/syslinux/mbr.bin > /dev/sdb
     
  5. Mount the USB flash drive.mount /dev/sdb1 /usbdisk 
  6. Mount the ESXi installer ISO image.mount -o loop VMware-VMvisor-Installer-5.0.0-XXXXXX.x86_64.iso /esxi_cdrom 
  7. Copy the contents of the ISO image to /usbdisk.
    cp -r /esxi_cdrom/* /usbdisk
     
  8. Rename the isolinux.cfg file to syslinux.cfg.
    mv /usbdisk/isolinux.cfg /usbdisk/syslinux.cfg
     
  9. In the file /usbdisk/syslinux.cfg, change the line APPEND -c boot.cfg  to APPEND -c boot.cfg -p 1. 
  10. Unmount the USB flash drive.umount /usbdisk 
  11. Unmount the installer ISO image.umount /esxi_cdrom 
The USB flash drive can now boot the ESXi installer.
Source of this Info:-
http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2004510

Thursday, 26 July 2012

Advanced Configuration options for VMware High Availability

Purpose

In the majority of environments, VMware High Availability (HA) default settings do not need to be changed. However, depending on your specific environment you may need to modify some HA options. This article describes the different configuration options available and how to apply them.

Resolution


Note: Not all configuration variables work in all versions of VirtualCenter/vCenter Server. As new variables are introduced in newer releases, they remain throughout later versions.

Applying a VMware HA customization

To access the various customizations available:
  1. Login to vCenter Server with VMware Infrastructure/vSphere Client as an administrator.
  2. Right-click the Cluster in the Inventory and select Edit Settings.
  3. Click VMware HA.
  4. Click the Advanced Options button.
  5. Enter Option and Value fields as appropriate (see below).
  6. Click OK.
  7. Click OK again.
  8. Wait for the Reconfigure Cluster task to complete and then right-click the Cluster again from the Inventory.
  9. Click Properties.
  10. Disable VMware HA and wait for the Reconfiguration Cluster task(s) to complete.
  11. Right-click the cluster and Enable VMware HA to have the settings take effect.

VMware High Availability Advanced options

These settings are available in VirtualCenter 2.0.0 and above:
  • das.defaultfailoverhost = <hostname>This option/value pair is used to set a preferred failover host, where <hostname> represents the short name of the preferred host. The host specified is used as the first choice in case of a failure. However, if there is insufficient capacity VMware HA automatically selects an alternate host.
  • das.isolationaddress = <value>This option/value pair changes the default isolation address, where <value> represents the IP address that is to be used as the isolation address. By default the address used is the Default Gateway address for the ESX host because it is a highly available address. This address is queried as one of the items in determining if an isolation response has occurred on the host, thus if this parameter is changed be sure to use a reliable, highly available IP address with as few failure points between it and the ESX host as possible.
These settings are available in VirtualCenter 2.x and above:
  • das.failuredetectiontime = <value>This option/value pair changes the default failure detection timeout, where <value> represents the failure time in milliseconds. VMware HA uses this timeout in declaring an isolation response, and does not declare a host as isolated until this timeout has been reached without any heartbeats received. By default the default failure detection time is 15 seconds (15000 ms). However, another common alternative is 60 seconds (60000 ms).

    Note: das.failuredetectiontime is no longer supported in vCenter Server 5.x. 

  • das.usedefaultisolationaddress = <value> 

    This option/value pair disables the use of the default gateway as an isolation address, where <value> is either true or false. By default this value is set to true. This parameter is generally used in conjunction with thedas.isolationaddress1 to das.isolationaddress10 parameter(s) listed below.
  • das.isolationaddress1 to das.isolationaddress10 = <value>These option/value pair(s) specify more than one alternate isolation address for VMware HA to use, where<value> represents the IP address to be used for isolation detection. When using more than one isolation address it is recommended that the das.failuredetectiontime parameter be increased to ensure proper failover detection can occur. Also, although up to 10 different isolation addresses can be specified one or two addresses should be sufficient for proper failover detection. For more information on setting multiple isolation addresses, see Setting Multiple Isolation Response Addresses for VMware High Availability (1002117).

    Note: The 
    das.isolationaddress parameter is still supported if you are not using more than one alternative isolation address.
These settings are available in VirtualCenter 2.5.0 and above:
  • das.powerOffOnIsolation = <value>

    T
    his option/value pair overrides the default isolation response setting to shutdown all the virtual machines when an isolation response occurs, where <value> is either true or false. By default this value is set to true. If changed to false all virtual machines will remain powered on in case of isolation.
  • das.vmMemoryMinMB = <value>

    T
    his option/value pair overrides the default memory slot size value used for admission control for VMware HA, where <value> is the amount of RAM in MB to be used for the calculation if there are no larger memory reservations. By default this value is set to 256MB.
  • das.vmCpuMinMHz = <value>This option/value pair overrides the default CPU slot size value used for admission control for VMware HA, where<value> is the amount of CPU in MHz to be used for the calculation if there are no larger CPU reservations. By default this value is set to 256MHz.
These settings are available in VirtualCenter 2.5.0 Update 2 and above:
  • das.conservativeCpuSlot = <value>

    This option/value pair reverts how conservative VMware HA is in regards to vCPU when calculating slot size for admission control, where <value> represents either a value of true or false. By default in VirtualCenter 2.5.0 Update 2 this option is false to make the admission control less conservative. If set to true it reverts to the behavior of admission control as it was VirtualCenter 2.5.0, and VirtualCenter 2.5.0 Update 1.
  • das.allowvMotionNetworks = <value>

    This option/value pair allows vMotion networks to be considered for VMware HA usage, where <value> represents a value of true or false. This parameter enables a host that only has one Network card configured for management and vMotion combined to be properly configured for VMware HA. By default this value is false, and any vMotion network is ignored.
  • das.allowNetwork[...]

    This option enables the use of port group names to control the networks used for HA. You can set the value to be "Service Console 2" or "Management Network" to use those port group names in the networking configuration.
This setting is available in VirtualCenter 2.5.0 Update 3 and above:
  • das.ignoreRedundantNetWarning = <value>
    To suppress the message Host <xxx> currently has no management network redundancy, which appears if the Service Console does not have network redundancy configured properly on ESX hosts in the VMware High Availability (HA) cluster or if the warning appears for a host already configured in a cluster, set the VMware HA advanced option das.ignoreRedundantNetWarning to true and reconfigure VMware HA on that host. For further information, see KB 1004700.
This setting is available in vCenter Server 4.x and above:
  • das.slotmeminmb

    This option defines the maximum bound on the memory slot size. If this option is used, the slot size is the smaller of this value or the maximum memory reservation plus memory overhead of any powered-on virtual machine in the cluster. 
  • das.slotcpuinmhz

    This option defines the maximum bound on the memory slot size. If this option is used, the slot size is the smaller of this value or the maximum memory reservation plus memory overhead of any powered-on virtual machine in the cluster. 
These settings are available in vCenter Server 5.0
  • das.ignoreinsufficienthbdatastore 
Disables configuration issues created if the host does not have sufficient heartbeat datastores for vSphere HA. Default value is false.
  • das.heartbeatdsperhost 
Changes the number of heartbeat datastores required. Valid values can range from 2-5 and the default is 2.
Check this Link for more info:-