vcva – Page 11

Quick Tip - Determining the vCenter Server OS platform (Windows or VCSA) using vSphere API

06.25.2015 by William Lam // Leave a Comment

The vSphere API is an extensively rich interface for being able to extract all sorts of useful information about your vSphere infrastructure. One useful trick that may come in handy for those requiring to perform operations directly against the vCenter Server guestOS itself is to figure out whether you are connecting to a Windows vCenter Server or the vCenter Server Appliance (VCSA)? Lets say you wish to automate the deployment of the recently released VSAN 6.0 Health Check Plugin and the process to install the plugin will differ between Windows vCenter Server and the VCSA, so it would be ideal if you can easily distinguish between the two

A simplistic solution would be to quickly test for something that would exist in either Windows or Linux, but what if you wanted to perform these operations using the vSphere API and the Guest Operations API to execute the commands within the guests? Well, luckily the vSphere API actually provides this information when connecting to a vCenter Server API endpoint and you can tell if you are connecting to a Windows vCenter Server or the VCSA.

To determine the guestOS type for the vCenter Server you are connecting to, there is a property called osType which you can query when you first connect. Below is a quick PowerCLI snippet for accessing this property, you can also use a variety of other vSphere SDKs to extract this property.

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

$server.ExtensionData.Content.About

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

The osType property for the VCSA is linux-x64

The osType property for vCenter Server for Windows is win32-x64

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.

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.