WilliamLam.com

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

by // 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.

Screen Shot 2015-06-14 at 7.06.39 AM
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

vcsa-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

by // 4 Comments

replicated-platform-services-controller-all-nodes-must-join-active-directory-0Last 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.

replicated-platform-services-controller-all-nodes-must-join-active-directory-1
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.

replicated-platform-services-controller-all-nodes-must-join-active-directory-2
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.

How should bulk operations such as adding ESXi hosts work?

by // 4 Comments

I had a meeting yesterday with a couple of Engineers to provide some feedback on a new project they were working on and they were interested in getting feedback on their  workflows but also my overall impression of the user experience (UX). One area that we had spent some time covering was on adding new resources such as an ESXi host which is performed using either a UI/API/CLI. In the case of adding an ESXi host, this was done sequentially and a user would need to specify multiple parameters like the hostname, IP Address, credentials, etc. and perform this task N-number of times until you had added all of the ESXi hosts that you wanted. Many of you are probably already familiar with this workflow as it exists in many of the current VMware products today when requiring to add a resource like an ESXi host.

I was wondering why this was the case and why not support a bulk add operation? This was not a new idea and in fact I and many others have asked about this in the past on why our own vSphere Web Client does not support bulk operations for some of the more common operations such as adding an ESXi host or provisioning a VM? In fact, I was actually reminded of this topic again this morning when I needed to mount an NFS Volume across multiple ESXi hosts and one of the new capabilities that was introduction in the vSphere Web Client over the vSphere C# Client was being able to bulk add an NFS Volume across multiple hosts.

Not only is this a useful capability to have but when you need to perform the same operation multiple times, there is also an increase of risk for making a mistake. Sure, if you mount the wrong NFS volume, you would have it wrong across all the hosts but this is no different if you were to Automate it from an API/CLI. I am sure some of you are probably saying, a simple for loop would do the trick and though I agree that would be the easiest way. However, it would be really nice that some of these operations would actually have native support for bulk operations from an API standpoint, that way this is not limited to just a UI-only feature which it is today. Even in the case of a simple for-loop, you are still executing the individual operation N-number of times versus being able to pass in a list and perform a single request and then rely on the backend implementation to properly handle the operation which could be done in parallel or sequentially depending on the type of operation.

Thinking about this a bit more, it may not be as simple as just adding bulk operation support into an API but there are also other things to consider. What happens when the resource you are adding has varying configurations, a classic example of this is adding multiple ESXi hosts. If they all have the same username and password, then you can provide the credentials once and then a list of ESXi hosts. What happens when they differ or in the worse case scenario, they all have different passwords? What happens when only a subset of the hosts are added, do you continue or fail all together?

I am actually curious to hear what others think about this and what your expectations would be? Both from a UI standpoint as well as from an Automation standpoint which includes API/CLI. Would a simple JSON/YAML configuration file that contains all hosts and credentials be acceptable with the option of having common global configurations and ability to override for individual entries? Would love to hear your thoughts on this and what you would be expecting? Perhaps this is something I can also share back with the Engineering teams as this is something I have been wanting to see for quite some time, especially when it comes to common operations like adding ESXi hosts and provisioning VMs.