WilliamLam.com

  • About
    • About
    • Privacy
  • VMware Cloud Foundation
  • VKS
  • Homelab
    • Hardware Options
    • Hardware Reviews
    • Lab Deployment Scripts
    • Nested Virtualization
    • Homelab Podcasts
  • VMware Nostalgia
  • Apple

Ghetto webAccess for ESXi

12.12.2011 by William Lam // 14 Comments

I got the idea for this post a few months back after noticing several questions on the VMTN forums on how to enable webAccess for ESXi. With ESXi, the webAccess interface is no longer available as it was with classic ESX. After seeing the question and randomly browsing through the various flings on VMware Labs, I noticed an interesting fling called Ops Panel for ESX. Ops Panel provides a simple javascript that leverages the vSphere MOB to perform basic power operations for virtual machines and it is loaded onto the homepage of a classic ESX host remotely using Greasemonkey.

I immediately wondered if I could run the javascript directly on an ESX or ESXi host without the use of Greasemonkey. With a quick tweak of the default index.html homepage, I was able to get a simple "ghetto" webAccess running on both an ESX and ESXi host. I also ran into several bugs, one that dealt with how the power state of a virtual machines was being captured by the differences in the ESX(i) 4.0, 4.1 and 5.0 APIs and a recent fix to a CSRF (Cross-Site Request Forgery) vulnerability in ESX(i) 4.1 Update 1 that made it difficult to get Ops Panel running on more than just ESX(i) 4.0.

I reached out to the fling creator Ivan Donchev and he was kind enough to help assist me in the issues I ran into and also provided an updated version of his script to properly handle both the power state and the CSRF workaround. He recently published an update to his script a few weeks back supporting both ESX 4 and ESXi 5 but missed ESX(i) 4.1 support due to limited amount of testing. This was an easy fix and I modified the script to include support for ESX(i) 4.1 and also changed the default power off operation to a guestOS shutdown. The modified version of the script can be downloaded here.

When you browse to the homepage of your ESX(i) host using the browser, you will be prompted to login which require the same credentials as if you were to login to the host directly using the vSphere Client or vSphere MOB.

Once you have logged in, it will search for all virtual machines running on the host and generate the list of virtual machines and their respective power states.

You can then perform the appropriate power operation such as a power on, shutdown or suspend using the icons on the right. This can be really useful if you don't have access to vCenter Server, vSphere Client or SSH access to the host but just have a web browser.

To load the Ops Panel script on an ESX(i) host, you will need to do the following:

Note: These instructions are applicable for both ESX and ESXi, but with ESXi, it is important that the commands to copy both the modified index.html and Ops Panel script to docroot are executed as changes are not persisted after a reboot for ESXi hosts.

You can also add this to your kickstart file by appending the lines above in your %firstboot stanza so you automatically get Ops Panel after install. Though this will not give you a full webAccess that classic ESX did but it definitely is a useful way to quickly get to your virtual machines and perform simple power operations using a web browser.

Categories // Uncategorized Tags // ESX 4.0, ESX 4.1, ESXi 4.1, ESXi 5.0, kickstart, mob, web access

How to Automate the Upgrade of Classic ESX 4.x to ESXi 5

08.16.2011 by William Lam // 3 Comments

In prior releases of ESXi, there was not a supported method of upgrading from classic ESX to ESXi, you had to perform a clean installation. With the release vSphere 5, ESXi is the only available option and providing a supported and easy method for migrating to ESXi will be very helpful for users. There are currently three options of migrating/upgrading from ESX 4.x to ESXi 5. Going forward in the future, two additional methods will be available for upgrading ESXi 5.x to subsequent update/patch releases.

Here is a table of the supported ESXi 5 upgrade options:

Upgrade Method Upgrade from ESX or ESXi 4.x to ESXi 5.0 Upgrade or Patch from ESXi 5.0 to ESXi 5.n
vSphere Update Manager yes yes
Interactive upgrade from CD, DVD, or USB drive yes yes
Scripted upgrade yes yes
vSphere Auto Deploy no yes
esxcli no yes

The first two options should be pretty straight forward and I won't go into any details, but if you are interested, check out Ivo Beeren's post here. If you decide to use VUM to perform you upgrade, make sure you check out this post about lopsided bootbanks before doing so. The 3rd option is a new feature in a kickstart installation and you now can specify two additional types of installation:

  • upgrade - Tries to perform an upgrade from ESX(i) 4.x to ESXi 5.x
  • installorupgrade - Tries to perform an upgrade from ESX(i) 4.x to ESXi 5.x, if it fails, it will perform a clean installation

In addition to the new installation types, there are two new options that can be specified:

  • --deletecosvmdk - If the system is being upgraded from ESX, remove the directory that contains the old Service Console VMDK file, cos.vmdk, to reclaim unused space in the VMFS datastore
  • --forcemigrate - If the host contains customizations, such as third-party VIBS or drivers, that are not included in the installer .ISO, the installer exits with an error describing the problem. The forcemigrate option overrides the error and forces the upgrade

Here is an example of kickstart specifically for upgrading from ESX 4.x to ESXi 5:

Note: One thing I noticed from the upgrade is that even if you specify a new root password, the current password is still preserved. Virtual machines located on local VMFS volumes will also be preserved as long as you do not use the --overwritevmfs option

You will also know that an ESXi 5 host was upgraded from ESX 4.x when you login to ESXi Shell, a motd will display a message.

As you can see you have several options of upgrading both ESX(i) 4.x to ESXi 5, though if you have a choice between an upgrade and reinstall, my personal preference would still be a clean installation via kickstart or host profiles.

Categories // Uncategorized Tags // ESXi 4.1, ESXi 5.0, kickstart, upgrade, vSphere 5.0

Automating ESXi 5 Kickstart Tips & Tricks

07.13.2011 by William Lam // 58 Comments

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.

Tip #1

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.

Tip #2 

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"

Tip #3

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

Tip #4

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

Tip #5

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.

Tip #6

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

Tip #7

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.

Tip #8

To create custom firewall rules, take a look at the blog post here. 

Tip #9

Here is post on how to create custom bootable ESXi ISO along with specifying static IP Address using kernel boot options.

Tip #10

Here is a post on how you can automate host cache configuration.   

Tip #11

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.

Tip #12
Here is a post on how to Disable LUN During ESXi Installation.

 

Tip #13 

Here is a post on Removing Previous Local Datastore Label for Reinstall in ESXi 5

 

Tip #14 

Here is a post on How to Deploy an OVF/OVA in the ESXi Shell

 

Tip #15

How to persist custom firewall rules in ESXi 5, take a look at these two articles here and here

Tip #16

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"

Categories // Uncategorized Tags // ESXi 5.0, kickstart, ks.cfg, vSphere 5.0

  • « Previous Page
  • 1
  • …
  • 8
  • 9
  • 10
  • 11
  • 12
  • Next Page »

Search

Thank Author

Author

William is Distinguished Platform Engineering Architect in the VMware Cloud Foundation (VCF) Division at Broadcom. His primary focus is helping customers and partners build, run and operate a modern Private Cloud using the VMware Cloud Foundation (VCF) platform.

Connect

  • Bluesky
  • Email
  • GitHub
  • LinkedIn
  • Mastodon
  • Reddit
  • RSS
  • Twitter
  • Vimeo

Recent

  • Ultimate Lab Resource for VCF 9.0 06/25/2025
  • VMware Cloud Foundation (VCF) on ASUS NUC 15 Pro (Cyber Canyon) 06/25/2025
  • VMware Cloud Foundation (VCF) on Minisforum MS-A2 06/25/2025
  • VCF 9.0 Offline Depot using Synology 06/25/2025
  • Deploying VCF 9.0 on a single ESXi host? 06/24/2025

Advertisment

Privacy & Cookies: This site uses cookies. By continuing to use this website, you agree to their use.
To find out more, including how to control cookies, see here: Cookie Policy

Copyright WilliamLam.com © 2025