WilliamLam.com

vCenter Server 6.0 Tidbits Part 12: New methods of downloading Support Bundles for VCSA / PSC

06.18.2015 by William Lam // Leave a Comment

Many of you are probably pretty familiar with the process of generating a VMware Support bundle for vCenter Server when it comes to troubleshooting or filing an SR with VMware GSS by using either the vSphere Web/C# Client UI. With the released of vSphere 6.0 and specifically with the vCenter Server Appliance (VCSA) there are now some additional methods in generating a VMware Support bundle which can come in handy if the vSphere Web Client is not running or if you wish to perform this simply through the command-line on a remote system.

The first option is simply by pointing your web browser to the following URL of your VCSA:

https://192.168.1.60/appliance/support-bundle

You will be prompted to login with a local account such as the "root" user which ensures that there is no dependency that SSO must be running which is the case when using the vSphere Web Client. Once authenticated, the VMware Support bundle will be generated and you will then be able to download it onto your system. The VMware Support Bundle is in the format of a compressed tar file which you can use gzip or tar to extract.

The second option is simply using cURL or wget from the command-line which you will also need to provide valid credentials to download. Here is an example of using curl and we will be saving the file as "support-bundle.tar.gz":

curl -k -u root -o support-bundle.tar.gz -O https://192.168.1.60/applmgmt/support-bundle

Once we have downloaded the VMware Support bundle to our desktop, we can then extract it using a variety of tools such as tar for example:

tar -zxvf support-bundle.tar.gz

In situations when you need to quickly resolve a problem by providing support logs to VMware, time is of the essence and being able to quickly generate the necessary support files can help lead to a quick resolution. Hopefully these additional methods of generating a VMware Support Bundle can help save you time when you may need to call upon them.

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

All replicated Platform Services Controller should be joined to Active Directory

06.16.2015 by William Lam // 4 Comments

Last week a colleague of mines was setting up a new vSphere 6.0 environment which contained a vCenter Server with an external Platform Services Controller (PSC) for our Management vSphere Cluster and another vCenter Server also with an external PSC for our Compute vSphere Cluster. The PSC's were configured to replicate with each other which meant they were part of the same SSO Domain providing us with the new Enhanced Linked Mode (ELM) feature that was introduced in vSphere 6.0.

With ELM, you can now easily view all of your vCenter Servers by logging into either of the vSphere Web Client Servers provided by any of the vCenter Servers that are connected to the replicated PSCs. In addition to providing a single view into your vSphere environment, data such as Licensing, Tags, VM Storage Policies, Roles/Permissions & Affinity/Anti-Affinity Rules to name a few are also replicated and made available to all the other vCenter Servers.

As part of the initial setup, my colleague had joined the first PSC (psc-01) to our Active Directory domain after completing the deployment of the VCSA, as the vSphere Web Client was required to make further changes to the PSC. The question that my colleague had was whether or not additional PSC nodes were required to be joined to the same Active Directory domain or would it automatically be handled by the PSC replication?

This was actually a great question and in fact something that could easily be overlooked or at least until you try to login using an Active Directory account and can not. What you will notice when going to the SSO Admin Configuration screen is that the Active Directory Identity Source has been added, so I can see why one would assume this would automatically be handled. If we take a closer look at my home lab environment and the Active Directory configuration within each of the PSC, we will see why this not the case.

If we take a look at the Active Directory configuration for psc-01, we can see that it is part of our AD Domain and the "Join" option is grayed out.

If we now take a look at psc-02, you will see that the Active Directory configuration is empty and the option to "Join" is still available.

To resolve this problem, you just need to add the additional PSC nodes to Active Directory and then reboot for the changes to go into affect. The PSC's also support different Active Directory domains as long as a trust relationship exists between the two, for more details take a look at this VMware KB 2064250. It should also be noted that this should not be an issue for those deploying a Windows based vCenter Server since it is usually a best practice to joined the Windows system to an AD Domain prior to installing additional software on top.