ESXi – Page 106

Automating silent installation of VMware Tools on Linux w/Automatic Kernel Modules

06.17.2015 by William Lam // 14 Comments

There was a recent question that was posted internally looking for a way to automate the silent installation of VMware Tools for Linux guest operating systems which also required enabling additional VMware Tools features like VMware's Automatic Kernel Modules. Currently, there are two options of installing VMware Tools for Linux guests, the first is by using VMware Tools Operating Specific Packages (OSPs) which can be found here or you can be manually install VMware Tools if an OSP does not exist or if you prefer to install interactively.

The second approach is what we will be focusing on and specifically with an emphasis on Automation 🙂 Once the VMware Tools installer is extracted, you will find a Perl script that does the actual magic called vmware-install.pl

The VMware Tools installer supports two modes of installation:

Interactive
Unattended with VMware defaults

The second option sounds like what we want but the problem is that the defaults have already been pre-selected by VMware and they can not be changed as far as I know. To use this option, you would specify the following:

./vmware-install.pl -d default

Here is a complete working snippet that I shared awhile back which will completely automate the installation of VMware Tools using the "default" method and is the quickest way to install VMware Tools for Linux guestOSes:

mkdir -p /mnt/vmw-tools && mount /dev/cdrom /mnt/vmw-tools && VMW_TOOLS=$(ls /mnt/vmw-tools/ | grep .gz) && cp -f /mnt/vmw-tools/${VMW_TOOLS} /tmp/ && umount /mnt/vmw-tools && rmdir /mnt/vmw-tools && tar -zxvf /tmp/${VMW_TOOLS} -C /tmp/ && cd /tmp/vmware-tools-distrib/ && ./vmware-install.pl -d default && rm -rf vmware-tools-distrib/ && rm -f /tmp/${VMW_TOOLS} && cd ~

view raw

gistfile1.txt

hosted with ❤ by GitHub

The solution above is great if you are okay with the defaults. However, if you wish to change any of the default settings such as the location of the installation or enabling additional VMware Tools capabilities, it is definitely not ideal. Unfortunately, as mentioned earlier these are the only two supported installation mechanisms. Now, just imagine you need to roll out a custom installation of VMware Tools and having to perform the installation manually, there must be a way right?

Luckily, there is and this is actually a trick that I have used for many installers which require some user interaction. Below is an updated script of performing a silent installation of VMware Tools, but instead of using the defaults I have created an "answer" file which contains the input that you would manually enter and redirecting that into the installer. In this particular case, I have left the system defaults in terms of the paths and documentation of where VMware Tools will be installed and focus on enabling additional capabilities such as VMware automatic kernel modules.

The last four lines in the answer file (no, no, yes, no) maps to the following VMware Tools capabilities:

VMware Host-Guest Filesystem
vmblock enables dragging or copying files
VMware automatic kernel modules
Guest Authentication

You can change these based on your requirements but the current script only enables "VMware automatic kernel modules". I think a great feature enhancement to the VMware Tools installer is the ability to accept a silent configuration file, so that this use case can be better supported and more resilient in case additional options are added.

	#!/bin/bash

	# Create temp workign directory
	mkdir -p /mnt/vmw-tools

	# Mount VMware Tools ISO
	mount /dev/cdrom /mnt/vmw-tools

	# Retrieve the VMware Tools package name from the directory
	VMW_TOOLS=$(ls /mnt/vmw-tools/ \| grep .gz)

	# Copy VMware Tools package to /tmp
	cp -f /mnt/vmw-tools/${VMW_TOOLS} /tmp/

	# Unmount the VMware Tools ISO
	umount /mnt/vmw-tools

	# Clean up and remove temp mount directory
	rmdir /mnt/vmw-tools

	# Extract VMware Tools installer to /tmp
	tar -zxvf /tmp/${VMW_TOOLS} -C /tmp/

	# Change into VMware Tools installer directory
	cd /tmp/vmware-tools-distrib/

	# Create silent answer file for VMware Tools Installer

	# If you wish to change which Kernel modules get installed
	# The last four entries (no,no,yes,no) map to the following:
	# VMware Host-Guest Filesystem
	# vmblock enables dragging or copying files
	# VMware automatic kernel modules
	# Guest Authentication
	# and you can also change the other params as well
	cat > /tmp/answer << __ANSWER__
	yes
	/usr/bin
	/etc
	/etc/init.d
	/usr/sbin
	/usr/lib/vmware-tools
	yes
	/usr/share/doc/vmware-tools
	yes
	yes
	no
	no
	yes
	no

	__ANSWER__

	# Install VMware Tools and redirecting the silent instlal file
	./vmware-install.pl < /tmp/answer

	# Final clean up
	rm -rf vmware-tools-distrib/
	rm -f /tmp/${VMW_TOOLS}
	cd ~

view raw

gistfile1.sh

hosted with ❤ by GitHub

How to create custom ESXi boot menu to support multiple Kickstart files?

06.11.2015 by William Lam // 31 Comments

I recently received a question from one of my readers who was looking to migrate from ESXi 4.1 to newer version and one of the challenges they faced was around their ESXi scripted installs, better known as ESXi Kickstart. Previously, they had relied on using a custom syslinux boot menu to be able to select a specific Kickstart configuration file that resided locally on a bootable ESXi Image (USB, ISO or CDROM) as a PXE/DHCP environment was not allowed in their environment. There was a small change to how ESXi boot files were reference between ESXi 4.x and ESXi 5.x/6.x and a new boot.cfg configuration is now used which I had written about here with respect to scripted installs when ESXi 5.0 was first released.

Luckily, even with these changes one can still use a custom menu with ESXi 5.x/6.x and be able to select a specific Kickstart configurations based on user input. Here is a screenshot example of a custom ESXi Image that I built providing three different install options that could be selected which would map to three different Kickstart configurations which can be either local to the boot media or can also be retrieved remotely.

The first thing you should be aware of if you plan to boot the custom ESXi Image from local media such as USB, CDROM or ISO is that the path to the Kickstart file must be in all UPPER CASE which is mentioned in this VMware KB 1026373. The next caveat that I found in my testing is that if you plan to store the local Kickstart files inside of a directory within the ESXi Image, the name of the directory can not be too long. I would recommend using "ks" as "kickstart" apparently was too long.

After you have extracted the contents of an ESXi ISO which you have downloaded, you will want to create a root directory called "ks" which will contain the different Kickstart configuration files. Here is an example of what structure look like:

ks
├── ks1.cfg
├── ks2.cfg
└── ks3.cfg

Next, you will need to edit the isolinux.cfg file which comes by default within the ESXi ISO. This is where you will add the different Kickstart options that a user will be able to select from. In this first example, we will look at referencing the Kickstart files locally on the media which can be either USB or CDROM and you will need to ensure you specify the right boot option as shown here in the VMware documentation. The path to the Kickstart file needs to be appended to the line that contains boot.cfg reference and you must ensure you include "+++" at the end of that line.

Here is an example of referencing a Kickstart file that lives on a USB device under this path /ks/ks.cfg:

APPEND -c boot.cfg ks=usb:/KS/KS.CFG +++

Here is an example of my isolinux.cfg for the boot menu that I have shown above which provides three different options mapping to three different Kickstart configuration files:

DEFAULT menu.c32
MENU TITLE vGhetto Custom ESXi 6.0 Boot Menu
NOHALT 1
PROMPT 0
TIMEOUT 80
LABEL Ghetto Install
  KERNEL mboot.c32
  APPEND -c boot.cfg ks=cdrom:/KS/KS1.CFG +++
  MENU LABEL ^1 Ghetto Install
LABEL A bit More Ghetto Install
  KERNEL mboot.c32
  APPEND -c boot.cfg ks=cdrom:/KS/KS2.CFG +++
  MENU LABEL ^2 A bit More Ghetto Install
LABEL Super Ghetto ESXi Install
  KERNEL mboot.c32
  APPEND -c boot.cfg ks=cdrom:/KS/KS3.CFG +++
  MENU LABEL ^3 Super Ghetto ESXi Install
LABEL hddboot
  LOCALBOOT 0x80
  MENU LABEL ^Boot from local disk

As I mentioned earlier, the Kickstart configuration file can either be retrieved locally or it can also be retireved remotely using one of the following supported protocols: http, https, ftp & nfs as shown here in the VMware documentation.

Here is an example of isolinux.cfg for a boot menu which references both a local kickstart as well as one that remotely lives on a web server:

DEFAULT menu.c32
MENU TITLE vGhetto Custom ESXi 6.0 Boot Menu
NOHALT 1
PROMPT 0
TIMEOUT 80
LABEL Ghetto Install
  KERNEL mboot.c32
  APPEND -c boot.cfg ks=cdrom:/KS/KS1.CFG +++
  MENU LABEL ^1 Ghetto Install
LABEL A bit More Ghetto Install
  KERNEL mboot.c32
  APPEND -c boot.cfg ks=http://172.30.0.108/ks/ks2.cfg +++
  MENU LABEL ^2 A bit More Ghetto Install
LABEL Super Ghetto ESXi Install
  KERNEL mboot.c32
  APPEND -c boot.cfg ks=http://172.30.0.108/ks/ks3.cfg +++
  MENU LABEL ^3 Super Ghetto ESXi Install
LABEL hddboot
  LOCALBOOT 0x80
  MENU LABEL ^Boot from local disk

For additional ESXi Kickstart resources and example, be sure to check out my pages here.

Retrieving statistics for a Distributed Virtual Port using the vSphere API & PowerCLI

06.01.2015 by William Lam // 2 Comments

Over the weekend I received an email from a fellow colleague over in the NSBU who was interested in retrieving statistics on an individual Distributed Virtual Port using the vSphere API and had asked if I had done this before. Although I have written about using the vSphere API to access various properties of a Distributed Virtual Switch (here & here) and migrating from a Virtual Standard Switch (VSS) to Distributed Virtual Switch (VDS) and from a VDS back to VSS (here & here), I have not done a whole lot with the vSphere API with regards to individual Distributed Virtual Ports.

Having said that, with the easy to use PowerCLI Distributed Virtual Switch cmdlets being available, it is actually not too difficult to retrieve this information using the vSphere API. For those of you who have not worked with a Distributed Virtual Switch before, to view the statistics of an individual Distributed Virtual Port, you must drill down into a specific Distributed Virtual Portgroup which you can find using either the vSphere Web/C# Client. Below is a screenshot from my vSphere Web Client.

To retrieve information on a Distributed Virtual Port using the vSphere API, you can refer to the DistributedVirtualPort property. Within this object, there is a state property which you can then drill down further to retrieve statistics using the stat property. If you would like to be able to pull other properties as shown in the screenshot, you can use the runtimeInfo property which provides additional information on the Distributed Virtual Port such as connected entity, MAC Address, VLAN ID, state, etc.

The following two PowerCLI VDS cmdlets: Get-VDPortgroup & Get-VDPort will help us retrieve the information we are looking. However, out of the box these cmdlets do not support pulling statistics for a Distributed Virtual Port. To do so, we will need to access the ExtensionData property which will allows us to access the underlying vSphere API from the PowerCLI object.

Below is a simple PowerCLI script which connects to a vCenter Server and retrieves a specific Distributed Virtual Portgroup (dvPg) that we are interested in using the Get-VDPortgroup cmdlet. Once we have the dvPg, we can then identify a specific Distributed Virtual Port (dvP) by using the Get-VDPort and passing in the dvPg from the previous command as well as the specific port by using the -key property. From here, we can then access a few properties from the dvP and most importantly, the statistics which we were originally interested in. In the example below, I am displaying the entire "stat" property, but you can easily filter out the specific stats you care about.

$server = Connect-VIServer -Server reflex.primp-industries.com

# Retrieve a Distributed Portgroup
$vdportgroup = Get-VDPortgroup -Name dv-vlan333

# Retrieve a specific Distributed Virtual Port from the Distributed Portgroup using the "key" property
$vdport = Get-VDPort -VDPortgroup $vdportgroup -Key 4

# Sample Distributed Virtual Port properties
Write-Host "Link Up: " $vdport.ExtensionData.State.RuntimeInfo.Linkup
Write-Host "Connectee: " $vdport.ExtensionData.State.RuntimeInfo.LinkPeer
Write-Host "Runtime MAC Address: " $vdport.ExtensionData.State.RuntimeInfo.macAddress

# Distributed Virtual Port Stats
$vdport.ExtensionData.State.Stats

Disconnect-VIServer -Server $server -Confirm:$false

Here is an example of the output from the script above and we can see that Distributed Virtual Port "4" matches to what we see in the vSphere Web Client screenshot.