WilliamLam.com

  • About
    • About
    • Privacy
  • VMware Cloud Foundation
  • VKS
  • Homelab
    • Resources
    • Nested Virtualization
  • VMware Nostalgia
  • Apple

ESXi 5.5 Kickstart script for setting up VSAN

07.21.2014 by William Lam // 12 Comments

In my lab, when I need to provision a new or rebuild an existing ESXi host, I still prefer to use the true and tried method of an unattended/scripted installation also known as Kickstart. Below is a handy ESXi 5.5 Kickstart that I have been using to setup a basic VSAN environment. I figure this might come in handy for anyone looking to automate their ESXi 5.5 deployment and include some of the VSAN configurations like creating a VSAN Disk Group or enabling VSAN Traffic type on a particular VMkernel interface. For more details about this Kickstart, refer to the bottom of the file where I break down the file in more detail.

# Sample kickstart for ESXi 5.5 configuring VSAN Disk Groups
# 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=$(esxcfg-route | awk '{print $5}')
DNS="172.30.0.100"
HOSTNAME=$(nslookup "${IPADDR}" "${DNS}" | grep Address | grep "${IPADDR}" | awk '{print $4}')

echo "network --bootproto=static --addvmportgroup=true --device=vmnic0 --ip=${IPADDR} --netmask=${NETMASK} --gateway=${GATEWAY} --nameserver=${DNS} --hostname=${HOSTNAME}" > /tmp/networkconfig

%firstboot --interpreter=busybox

vsan_syslog_key = "VSAN-KS"

logger $vsan_syslog_key " Enabling & Starting SSH"
vim-cmd hostsvc/enable_ssh
vim-cmd hostsvc/start_ssh

logger $vsan_syslog_key " Enabling & Starting ESXi Shell"
vim-cmd hostsvc/enable_esx_shell
vim-cmd hostsvc/start_esx_shell

logger $vsan_syslog_key " Suppressing ESXi Shell Warning"
esxcli system settings advanced set -o /UserVars/SuppressShellWarning -i 1

logger $vsan_syslog_key " Reconfiguring VSAN Default Policy"
esxcli vsan policy setdefault -c vdisk -p "((\"hostFailuresToTolerate\" i1) (\"forceProvisioning\" i1))"
esxcli vsan policy setdefault -c vmnamespace -p "((\"hostFailuresToTolerate\" i1) (\"forceProvisioning\" i1))"

logger $vsan_syslog_key "Enabling VSAN Traffic on vmk0"
esxcli vsan network ipv4 add -i vmk0

# assign license
vim-cmd vimsvc/license --set AAAAA-BBBBB-CCCCC-DDDDD-EEEEE

%firstboot --interpreter=python

import commands, os, uuid, syslog

vsan_syslog_key = "VSAN-KS"
debug = False

# Build VSAN Disk Group command based on vdq -q output
def createVsanDiskGroup():
	vdqoutput = eval(commands.getoutput("/sbin/vdq -q"))
	md = []
	ssd = ''
	for i in vdqoutput:
		if i['State'] == 'Eligible for use by VSAN':
			if i['Reason'] == 'Non-local disk':
				syslog.syslog(vsan_syslog_key + " Setting enable_local and reclaiming " + i['Name'])
				if debug == False:
					os.system("esxcli storage nmp satp rule add -s VMW_SATP_LOCAL -o enable_local -d " + i['Name'])
					os.system("esxcli storage core claiming reclaim -d " + i['Name'])
			if i['IsSSD'] == '1':
				ssd = i['Name']
			else:
				md.append(i['Name'])

	diskgroup_cmd = 'esxcli vsan storage add -s ' + ssd + ' -d ' + ' -d '.join(md)
	syslog.syslog(vsan_syslog_key + " Creating VSAN Disk Group using SSD: " + ssd +  " MD: " + ', '.join(md))
	if debug == False:
		os.system(diskgroup_cmd)

# Create VSAN Cluster (required only for first ESXi node)
def createVsanCluster():
	# generate UUID for VSAN Cluster
	vsan_uuid = str(uuid.uuid4())

	syslog.syslog(vsan_syslog_key + " Creating VSAN Cluster using UUID: " + vsan_uuid)
	if debug == False:
		os.system("esxcli vsan cluster join -u " + vsan_uuid)

createVsanDiskGroup()
createVsanCluster()

If you would like to see more details on creating ESXi Kickstart, make sure to check out my ESXi 4.x & 5.x examples here.

Line 6-9 This is generic Kickstart configurations specifying EULA, how to install, password, etc. You can refer to VMware's scripted install documentation.

Line 11-25 This extracts the DHCP IP Address (static allocation) and re-creates the network configuration in Line 25 for statically assigning the IP Address to the ESXi host

Line 27 This starts the firstboot script and assumes "Busybox" as the interpreter which means basic shell commands

Line 30 I create a custom key which will be logged in syslog for our installation

Line 32-41 Basic ESXi configurations leveraging vim-cmd and ESXCLI

Line 43-45 Configure the VSAN default storage policy, please refer to this article for more details.

Line 47-38 Configure the VSAN Traffic type on vmk0

Line 35 This starts a second firstboot script, but now using "Python"

Line 50-51 Assign a license to ESXi host

Line 53 Importing the appropriate libraries that will be used in the Python script

Line 58 Using the same custom key that I created earlier for logging to syslog

Line 61-81 A method for creating VSAN Disk Group by inspecting vdq CLI and marking disks as local

Line 83-90 A method for creating VSAN Cluster, please refer to this article for more details.

Line 92-93 Invoking the two Python methods. You can either create a custom Kickstart for your "first" ESXi node if you decide to bootstrap your VSAN Cluster onto a single ESXi host. You can also use custom boot options to specify whether the ESXi host being provisioned is the first or additional nodes. This topic is a bit advanced, but if you are interested, take a look at this article here.

Categories // Automation, ESXCLI, ESXi, VSAN, vSphere, vSphere 5.5 Tags // ESXi 5.5, kickstart, ks.cfg, VSAN, vSphere 5.5

How to generate specific support log bundles for vCenter & ESXi using vSphere API?

07.15.2014 by William Lam // 1 Comment

When an issue arises in your vSphere environment and you engage with VMware GSS, one of the first task you will mostly like be asked to perform is to generate a support log bundle and submit it. You can generate a support bundle using the vSphere Web/C# Client as seen in the screenshot below.

generating-support-bundle-vsphere-api-0
Last week I recieved a question from one of our development teams about generating support log bundles for both vCenter Server and ESXi hosts, but using the vSphere API instead of the UI. This functionality is available as part of the DiagnosticManager and the method you will want to call is GenerateLogBundles_Task() which allows you to specify which systems to collect support logs from. This by far is the easiest way if you just want to collect all logs and I will go into more detail in a bit on what I mean by this.

When invoking the GenerateLogBundles_Task(), support logs will be generated on each of the respective sub-systems which includes vCenter Server and the ESXi hosts. Once the log bundles have been created, the API will return a list of download URLs to the support log bundles. To demonstrate this functionality, I have created a sample vSphere SDK for Perl script called generateLogBundle.pl

The script assumes you want to collect ALL logs for both vCenter Server and ESXi hosts being managed by the given vCenter Server.

generating-support-bundle-vsphere-api-1
While working on the sample code, one thing I had noticed in the vSphere Web/C# Client is that you have the ability to select the specific logs to export.

generating-support-bundle-vsphere-api-2
I was looking through the vSphere API but I did not find a way to specify this level of granularity in the logs. I was of course curious and wondered if this was using some sort of private vSphere API (which I hoped was not the case). I decided to pull out one of my favorite tools when I get stuck with a question around the vSphere API which is Onyx. After manually generating the support log bundle and selecting a subset of the logs to export, I found out this process actually makes a call to a CGI script on the ESXi host called vm-support.cgi.

The list of available logs to export is generated by making a GET request to the following URL: https://[ESXI-HOSTNAME]/cgi-bin/vm-support.cgi?listmanifests=1

generating-support-bundle-vsphere-api-3
The output is an XML file that contains the manifest of the available logs to export in the log support bundle. To specify the specific logs to collect, you must provide the "id" property as seen in the screenshot above. In this example, I would like to collect the following: System:Base, VirtualMachines:GuestState, Storage:VSAN and VirtualMachines:diskinfo

To generate a support bundle from the ESXi host that contains the above, you will need to issue a GET request using the following URL: https://[ESXI-HOSTNAME]/cgi-bin/vm-support.cgi?manifests=System:Base VirtualMachines:GuestState Storage:VSAN VirtualMachines:diskinfo

This will instruct the ESXi host to generate the log bundle that contains the following manifest log files. To include others, you just need to append to the URL. You can easily test this out by pasting this URL into a web browser and providing your ESXi credentials and the logs will be available for download. Going back to my original observation, this is actually how vCenter Server provides the ability to export specific logs from each of the ESXi hosts when generating a support bundle.

If you would like to use the vSphere API to provide this same capability, you just need to leverage the AcquireGenericServiceTicket() API method which is available as part of the SessionManager and specify the URL for the support bundle. This will allow you to request a support log bundle from within vCenter Server without having to go directly to each of the ESXi hosts manually. You can see a very similar implementation of this API by taking a look at my How to efficiently transfer files to a datastore in vCenter using the vSphere API and specifically the efficent-upload-files-to-datastore.pl sample code.

Categories // Automation, ESXi, vSphere Tags // diagnostic manager, onyx, vc-support, vm-support, vm-support.cgi, vSphere API

What happens when Virtual Machines have duplicate instanceUUID's on ESXi?

07.03.2014 by William Lam // 8 Comments

While catching up on some email this morning, I received an interesting question from an internal engineer regarding the behavior when a duplicate instanceUUID is encountered on an ESXi host. An instanceUUID is a unique identifier that is used by vCenter Server to uniquely identify a Virtual Machine within a vCenter Server instance, I have written extensively about this topic here and here. The question that was brought up was what happens when a duplicate instanceUUID is encountered on a standalone/un-managed ESXi host and then it is added to vCenter Server?

I had theory on how this might work, but I figured I might as well try this out in the lab to be sure. I created two standalone ESXi hosts and created a Virtual Machine on each host and made sure that both had the same instanceUUID (yes, the ESXi host will actually generate the instanceUUID property regardless of being connected to a vCenter Server, I suspect this is mainly for a placeholder). I then add ESXi #1 to a vCenter Server and confirmed that the instanceUUID is still the same using the vSphere MOB. I then continue to add ESXi #2 to the vCenter Server and because a duplicate instanceUUID has been detected, vCenter Server automatically updates the second Virtual Machine with a new instanceUUID.

Before adding to vCenter Server:

  • ESXi-1
    • VM1 - InstanceUUID: 52b5e420-9d79-6095-cfdf-dfdd998d205e
  • ESXI-2
    • VM2 - InstanceUUID: 52b5e420-9d79-6095-cfdf-dfdd998d205e

After adding to vCenter Server:

  • ESXi-1
    • VM1 - InstanceUUID: 52b5e420-9d79-6095-cfdf-dfdd998d205e
  • ESXI-2
    • VM2 - InstanceUUID: 502db26b-c32d-6c32-cd6c-1ffc1549d269

An interesting observation that was made by the engineer while testing a similar scenario was that instead of having two ESXi hosts, he just had one. He was a bit surprised to see that the ESXi host actually allowed both Virtual Machines to be powered on even with a duplicate instanceUUID. The reason I believe this was allowed is that both Virtual Machines still had a unique MoRef Identifier along with unique BIOS UUID and more importantly, the instanceUUID property is ONLY used with vCenter Server. From the ESXi host point of view, it does not care if it has a duplicate instanceUUID as it is not used but will try to generate a unique one to begin. This was actually pretty interesting to know and the reason for the initial question was to ensure that the instanceUUID of a Virtual Machine is still the right property to uniquely identify a Virtual Machine within vCenter Server, which it is.

Categories // Automation, ESXi Tags // instanceUUID

  • « Previous Page
  • 1
  • …
  • 202
  • 203
  • 204
  • 205
  • 206
  • …
  • 224
  • 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

  • Programmatically accessing the Broadcom Compatibility Guide (BCG) 05/06/2025
  • Quick Tip - Validating Broadcom Download Token  05/01/2025
  • Supported chipsets for the USB Network Native Driver for ESXi Fling 04/23/2025
  • vCenter Identity Federation with Authelia 04/16/2025
  • vCenter Server Identity Federation with Kanidm 04/10/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

 

Loading Comments...