WilliamLam.com

Quick Tip - Pre-filled credentials in the vSphere 6.0 Web Client

by // 17 Comments

This past weekend I was finishing up a couple of demo recordings for my VMworld sessions in case the live demos fail for whatever reason, which has happened to me in the past. A few of the demos involve the vSphere Web Client UI and I thought instead of wasting time and potentially fat fingering credentials up on stage, I would try to do everything I can to remove any potential hiccups. In vSphere 6.0, the vCenter Single Sign-On page is now completely in HTML and this not only means you can customize the UI as I have shown here but you can also do some other neat tricks with it.

I decided to update the HTML page to automatically pre-fill both the SSO username and password, so that when I need to login to the vSphere Web Client, I just have to hit the tab key and then click on the login button.

prefilled-credentials
Disclaimer: Outside of a home lab or demo purposes, there is really no good reason for this. I can already hear Mike Foley sighing right now 😉 This also means that anyone who knows the address of your vSphere Web Client can just login, so you may want to only pre-fill the username and still type out the password in case you are concerned with that.

To pre-fill the value for the SSO username and/or password, you will need to edit the following file:

  • Windows VC: C:\ProgramData\VMware\vCenterServer\runtime\VMwareSTSService\webapps\websso\WEB-INF\views\unpentry.jsp
  • VCSA: /usr/lib/vmware-sso/vmware-sts/webapps/websso/WEB-INF/views/unpentry.jsp

For pre-filling the username, you will need to add a "value" property along with its actual value in the following section:

<input id="username" class="margeTextInput" type="text" value="*protected email*"/>

For pre-filling the password, you will need to add a "value" property along with its actual value in the following section:

<input id="password" class="margeTextInput" type="password" value="VMware1!"/>

Once you have saved your changes, you can then reload the browser and you should see that the vSphere Web Client now has both the username and password automatically pre-filled when the webpage loads.

Using latest PowerActions 1.5.0 to issue VMFS UNMAP API in vSphere 6.0 Web Client

by // 4 Comments

Last week, the popular PowerActions Fling was updated to version 1.5.0 which now finally adds support for vSphere 6.0. PowerActions is a vSphere Web Client Plugin that allows administrators to easily execute PowerCLI scripts against inventory objects within the vSphere Web Client. This is a very powerful capability that PowerActions is providing and allows users to easily extend new and custom operations that may not be available within the vSphere Web Client. One such example is being able to easily issue a VMFS UNAMP which in vSphere 5.5 was only available through the use of ESXCLI, I actually demonstrated how easy it is to provide this capability using PowerActions which you can read more about here.

With the release of vSphere 6.0, we now have the ability to issue a VMFS UNMAP using the vSphere API which I have blogged about here among other new vSphere 6.0 APIs. Given that PowerActions now supports vSphere 6.0, I figured this would be a good opportunity to take advantage of the new vSphere 6.0 API using the updated version of PowerActions. I have created a new PowerCLI script called Issue UNMAP 2.0 on Datastore.ps1 which now uses the new UnmapVmfsVolumeEx_Task vSphere API to perform the VMFS UNMAP. I have also submitted a new pull request for this example to Alan Renouf's PowerActions Github repository.

Here is a screenshot of my running the new VMFS UNMAP PowerActions operation against one of my vSphere Datastores and you can that it successfully completed in the Recent Tasks bar.

poweractions-vmfs-unmap
In addition to the new VMFS UNAMP operation that can be added as a PowerAction, here are just a few other examples of new vSphere 6.0 capabilities that you can easily extend into a PowerAction:

I am personally excited for the future and potential of PowerActions and I hope to see the PowerActions framework extend beyond just PowerCLI and support other scripting languages. I think this will be a very powerful capability that the vSphere Web Client can offer to our administrators, operators and developers.

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.