There is not a whole lot of changes for kickstart configurations between ESXi 5.1 and ESXi 5.0, majority of the tips and tricks noted in the ESXi 5.0 kickstart guide are still relevant for ESXi 5.1. Below are a few new tips and tricks (some old) as well as a complete working ESXi 5.1 kickstart example that can be used as a reference.
Search Results for: kickstart
Automating ESXi 5 Kickstart Tips & Tricks
There are some minor changes with kickstarting ESXi 5.0 but the majority of your existing ESXi 4.1 kickstart configurations can be re-used with a few modifications. One of my goals during the vSphere 5.0 beta was to automate as much of the configurations of an ESXi host as possible within the kickstart process. I also converted as many of the legacy esxcfg-* commands as I could over to the enhanced esxcli namespaces as the esxcfg-* commands will eventually be deprecated in favor of esxcli. Hopefully the tips & tricks and the example kickstart configuration file will be useful in aiding the transition to ESXi 5.0.
As usual, before diving in and creating an ESXi 5.0 kickstart configuration, make sure you spend some time going over the documentation provided by VMware, specifically the ESXi Installable and vCenter Server Setup Guide. If you would like to get a sense for what a ESXi 5.0 kickstart could look like, please jump to the bottom of this post to get a complete working example displaying the various types of configurations.
If you want to have your ESXi pxelinux configuration boot up to a kickstart configuration file, you have two methods of specifying this with ESXi 5.0.
The first is using the defualt installer method which specifies a new boot.cfg configuration file to contain all the boot parameters.
Here is an example of what the pxelinux default configuration file would look like:
Here is an example of what the boot.cfg looks like:
As you can see the default boot.cfg that is included in the ESXi 5.0 installer in the same directory as all the modules needed to boot up ESXi.
The second method is specifying the kickstart configuration file in the actual pxeboot file versus in a seperate boot.cfg file. This is similar to the old method of doing things, but you will have to also include all the entries that are in the boot.cfg if you decide to go down this route.
Here is an example of specifying ks.cfg in pxelinux default file:
Notice the "pxebooting ks=" stanza used to specify the ks.cfg configuration file and list of modules in boot.cfg. If you need to append additional parameters such as "IPAPPEND 1", you will need to add "+++" (three plus characters) at the very end of the module list separated with a new line for your additional entries. If you forget the "+++" symbols, you will not be able to successfully boot up the installer and an error will be thrown.
The default method of relying on the boot.cfg is the recommended approach. You can still append custom kernel parameters such as "IPAPPEND 1" which will still be in the pxelinux file, but your kickstart entry will now be part of the boot.cfg configuration file. Below is an example of the above configuration but leveraging the additional boot.cfg configuration file.
Here is an example of what the pxelinux file should look like:
As you can see, we still need to specify the "+++" to include additional parameters, but the pxelinux file is much cleaner now.
Here is an example of what the boot.cfg should look like:
As you can see, all we needed to do is append the following line "kernelopt=ks=http://172.30.0.108/esxi5/ks.cfg" which specifies the source to the kickstart configuration file.
This is not really a new tip, but definitely make use of the "dryrun" mode in the ks.cfg and reviewing the esxi_install.log and hostd.log for any errors. The logs will only persist upon the first reboot, if you specify a secondary reboot for whatever reason, these logs will be lost. If you would like to automate the copying of the installation logs to help debug/troubleshoot, you can copy them to a local VMFS. Here is a quick snippet that can be used (This assumes your local VMFS will have the name with the following format $(hostname -s)-local-storage-1):
cp /var/log/hostd.log "/vmfs/volumes/$(hostname -s)-local-storage-1/firstboot-hostd.log"
cp /var/log/esxi_install.log "/vmfs/volumes/$(hostname -s)-local-storage-1/firstboot-esxi_install.log"
VMware has once again and hopefully for the last time, changed what was known as Busybox Console, Unsupported Mode, Tech Support Mode to ESXi Shell. In doing so, the old vim-cmd to enable both local (TSM) and remote (SSH) to ESXi Shell needs to be updated.
To enable local ESXi Shell (previously known as Tech Support Mode) you will need to run the following commands to enable and start ESXi Shell.
vim-cmd hostsvc/enable_esx_shell
vim-cmd hostsvc/start_esx_shell
To enable remote ESXi Shell (previously known as TSM SSH) you will need to run the following commands to enable and start remote ESXi Shell for SSH support.
vim-cmd hostsvc/enable_ssh
vim-cmd hostsvc/start_ssh
Note: During the beta, there was actually an intermediate name for this which was known as ESX Shell but through our feedback, we had recommended ESXi Shell so that users do not confuse old classic ESX with ESXi and this may or may not change from the actual vim-cmd's
The --level XX that would specify when a %firstboot script would execute is no longer supported and deprecated in ESXi 5.0. By default all %firstboot script will automatically execute after all default ESXi start up scripts have finished running. The location of the %firstboot scripts are in /etc/rc.local.d/001.fireboot_001
You should be able leverage the new changes in esxcli to configure majority of your ESXi 5.0 hosts, the are various examples below in the example kickstart. There are still a few things that are currently not included in esxcli such as configuring NTP, host licensing, ESXi Shell, SSH, and a few others that rely on vim-cmd or some minor hacks. VMware recommends you start to get familiar with esxcli, as the old esxcfg-* will eventually be deprecated and removed in future vSphere releases and be completely replaced with esxcli.
You now have the ability to configure multiple syslog hosts with ESXi 5.0 but also the ability to control individual loggers such as for vmkernel, hostd, vpxa, fdm, etc. Here is an example of changing the default syslog rotation from 10 to 20 and specifying two syslog hosts:
esxcli system syslog config set --default-rotate 20 --loghost syslog1.primp-industries.com:514,syslog2.primp-industries.com:1514
Note: The new syslog facility supports tcp,udp and tcps but there is a syntax bug on how to specify normal tcp, udp and or tcps.
By default, TCP is assumed and you can specify that using the following formats:
syslog1.primp-industries.com:514
tcp://syslog1.primp-industries.com:514
To specify UDP, you will need to use the following syntax:
udp://syslog1.primp-industries.com:514
To specify TCPS, you will need to use the following syntax:
ssl://syslog1.primp-industries.com:514
To view the individual syslog types, you can run the following command:
esxcli system syslog config logger list
To update the individual syslog types, you can run the following command:
esxcli system syslog config logger set --id=fdm --rotate=20 --size=2048
In ESXi 4.1, to enable the SSH security banner, you had to make some minor hacks. With ESXi 5, there is not an official sshd_config and you can configure the security banner by editing /etc/issue. You can also edit the motd under /etc/motd.
To create custom firewall rules, take a look at the blog post here.
Here is post on how to create custom bootable ESXi ISO along with specifying static IP Address using kernel boot options.
Here is a post on how you can automate host cache configuration.
If you are going to SSH out of an ESXi host at any point (%post, %firstboot) ensure that you enable sshClient via the ESXi firewall else you will get a connection denied. To enable the ESXi firewall use the following command:
esxcli network firewall ruleset set --ruleset-id sshClient --enabled yes
Note: If you're doing this during %post section, hostd is not running and you will need to use "localcli" to enable the firewall which by-passes hostd.
Here is a post on how to Disable LUN During ESXi Installation.
How to persist custom firewall rules in ESXi 5, take a look at these two articles here and here
Here is a post on Configuring ESXi Power Management Policy Using the CLI
Tip #17
Here's an article about creating custom VIB for ESXi 5.0
Here is a complete working example of an ESXi 5.0 kickstart that can help you convert your existing ESX(i) 4.x to ESXi 5.x
# Sample kickstart for ESXi 5.1 # William Lam # www.virtuallyghetto.com ######################################### accepteula install --firstdisk --overwritevmfs rootpw vmware123 reboot %include /tmp/networkconfig %pre --interpreter=busybox # extract network info from bootup VMK_INT="vmk0" VMK_LINE=$(localcli network ip interface ipv4 get | grep "${VMK_INT}") IPADDR=$(echo "${VMK_LINE}" | awk '{print $2}') NETMASK=$(echo "${VMK_LINE}" | awk '{print $3}') GATEWAY=$(localcli network ip route ipv4 list | grep default | awk '{print $3}') DNS="172.30.0.100,172.30.0.200" HOSTNAME=$(nslookup "${IPADDR}" "${DNS}" | grep Address | grep "${IPADDR}" | awk '{print $4}') echo "network --bootproto=static --addvmportgroup=false --device=vmnic0 --ip=${IPADDR} --netmask=${NETMASK} --gateway=${GATEWAY} --nameserver=${DNS} --hostname=${HOSTNAME}" > /tmp/networkconfig %firstboot --interpreter=busybox # enable VHV (Virtual Hardware Virtualization to run nested 64bit Guests + Hyper-V VM) grep -i "vhv.enable" /etc/vmware/config || echo "vhv.enable = \"TRUE\"" >> /etc/vmware/config # enable & start remote ESXi Shell (SSH) vim-cmd hostsvc/enable_ssh vim-cmd hostsvc/start_ssh # enable & start ESXi Shell (TSM) vim-cmd hostsvc/enable_esx_shell vim-cmd hostsvc/start_esx_shell # supress ESXi Shell shell warning - Thanks to Duncan (http://www.yellow-bricks.com/2011/07/21/esxi-5-suppressing-the-localremote-shell-warning/) esxcli system settings advanced set -o /UserVars/SuppressShellWarning -i 1 # ESXi Shell interactive idle time logout esxcli system settings advanced set -o /UserVars/ESXiShellInteractiveTimeOut -i 3600 # Change the default ESXi Admins group "ESX Admins" to a custom one "Ghetto ESXI Admins" for AD vim-cmd hostsvc/advopt/update Config.HostAgent.plugins.hostsvc.esxAdminsGroup string "Ghetto ESXi Admins" # Users that will have full access to DCUI even if they don't have admin permssions on ESXi host vim-cmd hostsvc/advopt/update DCUI.Access string root,william,tuan # Block VM guest BPDU packets, global configuration esxcli system settings advanced set -o /Net/BlockGuestBPDU -i 1 # copy SSH authorized keys & overwrite existing wget http://air.primp-industries.com/esxi5/id_dsa.pub -O /etc/ssh/keys-root/authorized_keys # disable SSH keys - uncomment the next section # sed -i 's/AuthorizedKeysFile*/#AuthorizedKeysFile/g' /etc/ssh/sshd_config # rename local datastore to something more meaningful vim-cmd hostsvc/datastore/rename datastore1 "$(hostname -s)-local-storage-1" # assign license vim-cmd vimsvc/license --set AAAAA-BBBBB-CCCCC-DDDDD-EEEEE ## SATP CONFIGURATIONS ## esxcli storage nmp satp set --satp VMW_SATP_SYMM --default-psp VMW_PSP_RR esxcli storage nmp satp set --satp VMW_SATP_DEFAULT_AA --default-psp VMW_PSP_RR ########################### ## vSwitch configuration ## ########################### ##################################################### # vSwitch0 : Active->vmnic0,vmnic1 Standby->vmnic2 # failback: yes # faildectection: beacon # load balancing: portid # notify switches: yes # avg bw: 1000000 Kbps # peak bw: 1000000 Kbps # burst size: 819200 KBps # allow forged transmits: yes # allow mac change: no # allow promiscuous no # cdp status: both # attach vmnic1,vmnic2 to vSwitch0 esxcli network vswitch standard uplink add --uplink-name vmnic1 --vswitch-name vSwitch0 esxcli network vswitch standard uplink add --uplink-name vmnic2 --vswitch-name vSwitch0 # configure portgroup esxcli network vswitch standard portgroup add --portgroup-name VMNetwork1 --vswitch-name vSwitch0 esxcli network vswitch standard portgroup set --portgroup-name VMNetwork1 --vlan-id 100 esxcli network vswitch standard portgroup add --portgroup-name VMNetwork2 --vswitch-name vSwitch0 esxcli network vswitch standard portgroup set --portgroup-name VMNetwork2 --vlan-id 200 esxcli network vswitch standard portgroup add --portgroup-name VMNetwork3 --vswitch-name vSwitch0 esxcli network vswitch standard portgroup set --portgroup-name VMNetwork3 --vlan-id 333 # configure cdp esxcli network vswitch standard set --cdp-status both --vswitch-name vSwitch1 ### FAILOVER CONFIGURATIONS ### # configure active and standby uplinks for vSwitch0 esxcli network vswitch standard policy failover set --active-uplinks vmnic0,vmnic1 --standby-uplinks vmnic2 --vswitch-name vSwitch0 # configure failure detection + load balancing (could have appended to previous line) esxcli network vswitch standard policy failover set --failback yes --failure-detection beacon --load-balancing portid --notify-switches yes --vswitch-name vSwitch0 ### SECURITY CONFIGURATION ### esxcli network vswitch standard policy security set --allow-forged-transmits yes --allow-mac-change no --allow-promiscuous no --vswitch-name vSwitch0 ### SHAPING CONFIGURATION ### esxcli network vswitch standard policy shaping set --enabled yes --avg-bandwidth 100000 --peak-bandwidth 100000 --burst-size 819200 --vswitch-name vSwitch0 ##################################################### # vSwitch1 : Active->vmnic3,vmnic4 Standby->vmnic5 # failback: no # faildectection: link # load balancing: mac # notify switches: no # allow forged transmits: no # allow mac change: no # allow promiscuous no # cdp status: listen # mtu: 9000 # add vSwitch1 esxcli network vswitch standard add --ports 256 --vswitch-name vSwitch1 # attach vmnic3,4,5 to vSwitch0 esxcli network vswitch standard uplink add --uplink-name vmnic3 --vswitch-name vSwitch1 esxcli network vswitch standard uplink add --uplink-name vmnic4 --vswitch-name vSwitch1 esxcli network vswitch standard uplink add --uplink-name vmnic5 --vswitch-name vSwitch1 # configure mtu + cdp esxcli network vswitch standard set --mtu 9000 --cdp-status listen --vswitch-name vSwitch1 # configure portgroup esxcli network vswitch standard portgroup add --portgroup-name NFS --vswitch-name vSwitch1 esxcli network vswitch standard portgroup add --portgroup-name FT_VMOTION --vswitch-name vSwitch1 esxcli network vswitch standard portgroup add --portgroup-name VSPHERE_REPLICATION --vswitch-name vSwitch1 ### FAILOVER CONFIGURATIONS ### # configure active and standby uplinks for vSwitch1 esxcli network vswitch standard policy failover set --active-uplinks vmnic3,vmnic4 --standby-uplinks vmnic5 --vswitch-name vSwitch1 # configure failure detection + load balancing (could have appended to previous line) esxcli network vswitch standard policy failover set --failback no --failure-detection link --load-balancing mac --notify-switches no --vswitch-name vSwitch1 ### SECURITY CONFIGURATION ### esxcli network vswitch standard policy security set --allow-forged-transmits no --allow-mac-change no --allow-promiscuous no --vswitch-name vSwitch1 # configure vmkernel interface for NFS traffic, FT_VMOTION and VSPHERE_REPLICATION traffic VMK0_IPADDR=$(esxcli network ip interface ipv4 get | grep vmk0 | awk '{print $2}') VMK1_IPADDR=$(echo ${VMK0_IPADDR} | awk '{print $1".51."$3"."$4}' FS=.) VMK2_IPADDR=10.10.0.2 VMK3_IPADDR=10.20.0.2 esxcli network ip interface add --interface-name vmk1 --mtu 9000 --portgroup-name NFS esxcli network ip interface ipv4 set --interface-name vmk1 --ipv4 ${VMK1_IPADDR} --netmask 255.255.255.0 --type static esxcli network ip interface add --interface-name vmk2 --mtu 9000 --portgroup-name FT_VMOTION esxcli network ip interface ipv4 set --interface-name vmk2 --ipv4 ${VMK2_IPADDR} --netmask 255.255.255.0 --type static esxcli network ip interface add --interface-name vmk3 --mtu 9000 --portgroup-name VSPHERE_REPLICATION esxcli network ip interface ipv4 set --interface-name vmk3 --ipv4 ${VMK3_IPADDR} --netmask 255.255.255.0 --type static # Configure VMkernel traffic type (Management, VMotion, faultToleranceLogging, vSphereReplication) esxcli network ip interface tag add -i vmk2 -t Management esxcli network ip interface tag add -i vmk2 -t VMotion esxcli network ip interface tag add -i vmk2 -t faultToleranceLogging esxcli network ip interface tag add -i vmk3 -t vSphereReplication # Configure VMkernel routes esxcli network ip route ipv4 add -n 10.20.183/24 -g 172.30.0.1 esxcli network ip route ipv4 add -n 10.20.182/24 -g 172.30.0.1 # Disable IPv6 for VMkernel interfaces esxcli system module parameters set -m tcpip3 -p ipv6=0 ### MOUNT NFS DATASTORE ### esxcli storage nfs add --host 172.51.0.200 --share /volumes/Primp/primp-6 --volume-name himalaya-NFS-primp-6 ### ADV CONFIGURATIONS ### esxcli system settings advanced set --option /Net/TcpipHeapSize --int-value 30 esxcli system settings advanced set --option /Net/TcpipHeapMax --int-value 120 esxcli system settings advanced set --option /NFS/HeartbeatMaxFailures --int-value 10 esxcli system settings advanced set --option /NFS/HeartbeatFrequency --int-value 20 esxcli system settings advanced set --option /NFS/HeartbeatTimeout --int-value 10 esxcli system settings advanced set --option /NFS/MaxVolumes --int-value 128 ### SYSLOG CONFIGURATION ### esxcli system syslog config set --default-rotate 20 --loghost vcenter50-3.primp-industries.com:514,udp://vcenter50-3.primp-industries.com:514,ssl://vcenter50-3.primp-industries.com:1514,udp://vcenter50-3.primp-industries.com:514,udp://vcenter50-3.primp-industries.com:514,ssl://vcenter50-3.primp-industries.com:1514,ssl://vcenter50-3.primp-industries.com:1514 # change the individual syslog rotation count esxcli system syslog config logger set --id=hostd --rotate=20 --size=2048 esxcli system syslog config logger set --id=vmkernel --rotate=20 --size=2048 esxcli system syslog config logger set --id=fdm --rotate=20 esxcli system syslog config logger set --id=vpxa --rotate=20 ### NTP CONFIGURATIONS ### cat > /etc/ntp.conf << __NTP_CONFIG__ restrict default kod nomodify notrap noquerynopeer restrict 127.0.0.1 server 0.vmware.pool.ntp.org server 1.vmware.pool.ntp.org __NTP_CONFIG__ /sbin/chkconfig ntpd on ### FIREWALL CONFIGURATION ### # enable firewall esxcli network firewall set --default-action false --enabled yes # services to enable by default FIREWALL_SERVICES="syslog sshClient ntpClient updateManager httpClient netdump" for SERVICE in ${FIREWALL_SERVICES} do esxcli network firewall ruleset set --ruleset-id ${SERVICE} --enabled yes done # backup ESXi configuration to persist changes /sbin/auto-backup.sh # enter maintenance mode esxcli system maintenanceMode set -e true # copy %first boot script logs to persisted datastore cp /var/log/hostd.log "/vmfs/volumes/$(hostname -s)-local-storage-1/firstboot-hostd.log" cp /var/log/esxi_install.log "/vmfs/volumes/$(hostname -s)-local-storage-1/firstboot-esxi_install.log" # Needed for configuration changes that could not be performed in esxcli esxcli system shutdown reboot -d 60 -r "rebooting after host configurations"
How to automatically add ESX(i) host to vCenter in Kickstart
While recently updating my Automating Active Directory Domain Join in ESX(i) Kickstart article, it reminded me an old blog post by Justin Guidroz who initially identified a way to add an ESXi host to vCenter using python and the vSphere MOB. The approach was very neat but was not 100% automated as it required some user interaction with the vSphere MOB to identify certain API properties before one could potentially script it within a kickstart installation.
I decided to revisit this problem as it was something I had investigated awhile back. There are numerous ways on getting something like this to work in your environment, but it all boils down to your constraints, naming convention and provisioning process. If you have a well defined environment and utilizing a good naming structure and can easily identify which vCenter a given ESX(i) host should be managed from, then this can easily be integrated into your existing kickstart with minor tweaks. This script was tested on vCenter 4.1 Update 1 and ESXi 4.1 and 4.1 Update1.
UPDATE (03/29/2011): Updated the IP Address extraction to use gethostbyname and added proper logout logic after joining vCenter.
UPDATE (02/01/2013): I have provided a download link to the joinvCenter.py script below as there have been some funky formatting issues when displaying the script. For ESXi 5.x hosts, you will need to ensure httpClient is enabled (disabled by default) on the ESXi firewall else it will not be able to connect to your vCenter Server. Please refer below for the instructions.
There are a few steps that are necessary before we get started and a recommended one for those that have security concerns around this solution.
Step 1 - You will need to extract some information from the vCenter server in which you would like your ESX(i) hosts to join. You will need to generate an inventory path to the vCenter cluster which will take the form of: [datacenter-name]/host/[cluster-name], this will automatically locate the managed object ID of your vCenter cluster which is required as part of the host add process. This was a manual process in Justin's original solution.
In this example, I have a datacenter called "Primp-Skunkworks" and a cluster under that datacenter called "Primp-Skunkworks-Cluster", the inventory path will look like the following:
"Primp-Skunkworks/host/Primp-Skunkworks-Cluster"
You will need this value to populate a variable in the script which will be described a little bit later
Step 2 - As you may have guessed, to add an ESX(i) host to vCenter, you will need to connect to vCenter server and use an account that has the permission to add a host. It is recommended that you do not use or expose any administrative accounts for this as the credentials are stored within the script unencrypted. A work around is to create a service account whether that is a local account or an Active Directory account with only the permission to add an ESX(i) host to a vCenter cluster. You will create a new role, in this example I call it "JoinvCenter" and you just need to provide the Host->Inventory->Add host to cluster privilege.
Once you have created the role, you will need to assign this role to the service account user either globally in vCenter if you want to add to multiple cluster or a given datacenter/cluster.
Now that we have the pre-requisites satisfied, we will need to populate a few variables within the script which will be used in your %post section of ESX(i) kickstart configuration file.
This variable defines the name of your vCenter server, please provide the FQDN:
This variable define the vCenter cluster path which was generated earlier:
These variables define the server account credentials used to add an ESX(i) host to vCenter. You will need to run the following command to encode the selected password. You will need access to a system with python interpreter to run the following command:
python -c "import base64;
print base64.b64encode('MySuperDuperSecretPasswordYo')"
Note: This does not encrypt your password but obfuscate it slightly so that you are not storing the password in plain text. If a user has access to the encoded hash, it is trivial to decode it.
These variables define the ESX(i) root credentials which is required as part of the vCenter add process. If you do not want to store these in plain text, you will also need to encode them using the command in previous section:
We are now all done and ready to move forward with the actual script which will be included in your kickstart configuration. As a sanity check, you can run this script manually on an existing ESX(i) host to ensure that the process works before testing in kickstart. For ESXi 5.x hosts, ensure httpClient firewall ruleset is enabled by following ESXCLI command:
esxcli network firewall ruleset set -e true -r httpClient
You should also ensure this is the very last script to execute as I ran into a race condition while the root password was being updated automatically from the default 999.* scripts. To ensure this is the very last script, set the --level to something like 9999 in your %firstboot stanza
Download: joinvCenter.py
To aide in troubleshooting, the script also outputs the details to syslog and on ESX(i), it will be stored in /var/log/messages and you can just search for the string "GHETTO-JOIN-VC". If everything is successful, after %firstboot section has completed, you should be able to see an ESX(i) host join vCenter and the following in the logs.
Tips: You should only see "Success" messages, if you see any "Failed" messages, something went wrong. If you are still running into issues, make sure your ESX(i) host has it's hostname configured with FQDN and you should see an error on your vCenter server if it fails to whether it's due to hostname and/or credentials. You can also redirect the output of the script to local VMFS volume for post-troubleshooting.
Depending on your provision process and how you determine which ESX(i) host should join which vCenter/cluster, you can easily add logic in the main kickstart configuration file to automatically determine or extract from a configuration file and dynamically update joinvCenter.py script prior to execution.
I would like to thank Justin Guidroz and VMTN user klich for their contributions on the python snippets that were used in the script.
FYI - I am sure the python code could be cleaner but I will leave that as an exercise for those more adept to python. My python-fu is not very strong 😉
- « Previous Page
- 1
- …
- 3
- 4
- 5
- 6
- 7
- …
- 31
- Next Page »