WilliamLam.com

Getting Rid of the Inventory Tree in the New vSphere Web Client

by // 2 Comments

I don't know about you, but I really like using the new inventory list compared to the old inventory tree when I need to find something in new vSphere Web Client. The inventory list does not rely on the static and limited hierarchical tree view to display your vSphere objects. Instead, it groups common vSphere objects together (works across multiple vCenter Servers) along with links to other related objects. This allows you to quickly navigate to a particular vSphere object and with just a click away to other related objects for further inspection. Finally, you will no longer have to worry about the "white screen of death" which was a common problem when trying to display huge inventories and sometimes even smaller ones while using the tree view.

To be honest, I was not a fan of the inventory list at first, but after spending some time with it, I quickly realized the benefits of moving away from the old hierarchical tree view. I actually like the new inventory list so much, that I personally wanted like to get rid of the inventory tree view as it is an extra mouse movement to get to the inventory list. I sometimes even accidentally click on the inventory tree when browsing too quickly through the vSphere Web Client.

I thought it might be a long shot to see if it was possible to remove the inventory tree since I assumed it might be part of the compiled code. Surprisingly, I found out from one of the developers, there was actually a pretty simple way (aka "hack") of removing the inventory tree.

Disclaimer: This is probably not officially supported by VMware, please use at your own risk.

In the example below, I am using the VCSA (vCenter Server Appliance) which has the vSphere Web Client installed by default but this should also work for a Windows vCenter Server that has the vSphere Web Client Server installed.

Step 1 - We need to make a backup of the following file /usr/lib/vmware-vsphere-client/plugin-packages/vsphere-client/plugins/inventory-viewer-war-5.1.0.war which contains the file that we need to edit. The command below will just make a backup copy called inventory-viewer-war-5.1.0.war.BAK

cp /usr/lib/vmware-vsphere-client/plugin-packages/vsphere-client/plugins/inventory-viewer-war-5.1.0.war /usr/lib/vmware-vsphere-client/plugin-packages/vsphere-client/plugins/inventory-viewer-war-5.1.0.war.BAK

Step 2 - Next, we will go ahead and extract the contents of the WAR file which is basically a zip archive in our home directory so that we can edit a file. Run the following command which will extract the contents into a directory called TEMP under /root.

unzip /usr/lib/vmware-vsphere-client/plugin-packages/vsphere-client/plugins/inventory-viewer-war-5.1.0.war -d ~/TEMP

Step 3 - Change into the ~/TEMP directory and you should see a file called plugin.xml which we will be editing. Use an editor such as vi and locate the following section and comment it all out using the notation as shown below
Step 4 - Once you have finished editing the plugin.xml file, go ahead and save the file. Now we will need to re-create the inventory-viewer-war-5.1.0.war file and to do so, inside the TEMP directory, run the following command:

zip -r inventory-viewer-war-5.1.0.war *

Step 5 - We now need to copy the modified inventory-viewer-war-5.1.0.war back into the vSphere Client Plugins directory. Run the following command to copy the WAR file into plugins directory:

cp inventory-viewer-war-5.1.0.war /usr/lib/vmware-vsphere-client/plugin-packages/vsphere-client/plugins/inventory-viewer-war-5.1.0.war

Step 6- Finally, for the changes to go into effect, we just need to restart the vSphere Web Client service by running the following command:

/etc/init.d/vsphere-client restart

If everything was successful, then you should be able to login to the vSphere Web Client and when you click on the main vCenter home on the left, you should no longer see the inventory tree view, just the inventory lists.

Even though we removed the inventory tree from the object navigator, you can still access the four tree views using the shortcuts found on the home page:

If you really want to disable those as well, you can comment out the following four sections:
OR better yet, re-link them to the main vCenter home view by adjusting the targetViewUid to point to vsphere.core.viHome.domainView

Using the New vCloud Networking and Security to Load Balance Multiple vSphere Web Client Servers

by // 1 Comment

If you followed my previous two articles Configuring Additional Windows vSphere Web Client 5.1 Servers & Configuring Additional VCSA 5.1 as vSphere Web Client Servers I demonstrated how easy it is to add additional vSphere Web Client Servers to provide additional connection load balancing as well as redundancy in accessing your vSphere 5.1 environment. The next logical step is to actually place a load balancer in front of all the vSphere Client Servers to provide a single entry point for users to connect to.

I did a quick search for some load balancer solutions for testing, but found that they were quite complex and non-intuitive to setup. Since this was for my home lab, I decided to try out the new vCloud Networking & Security 5.1 (previously known as vShield). This being my first time setting up a load balancer (usually a task given to Network Engineers), I was pleasantly surprised and shocked at how easy it was to deploy and configure a load balancer using the new vCloud Networking and Security. Instead of going through this step by step, I thought I record a quick video.

The video below shows how you can leverage the new vCloud Networking & Security 5.1 to deploy and configure a Load Balancer to load balance multiple vSphere Web Client Servers.

If you have not tried out the new vCloud Networking and Security, I highly recommend you give it a try, especially with all the new network and security features in the latest 5.1 release.

Changing GuestOS Type Using a Custom vCO Workflow in the vSphere Web Client

by // 6 Comments

Something you might not have noticed, is the fact that you can not change or modify the guestOS type after a virtual machine has been created in the new vSphere Web Client, this option is just grayed out.

Though this is a change in behavior compared to the old vSphere C# Client, I actually took this as an opportunity to try out one of the most interesting and unrealized feature in the vSphere 5.1 release. This feature being a tighter integration between vCenter Server and vCenter Orchestrator. This means that you can now take any of your existing vCO workflows or create new workflows and make them directly available to any of the vSphere objects within the new vSphere Web Client as a custom action. 

Note: A feature request/bug has already been filed with VMware to have the ability to change the Guest OS and Guest OS Version for a virtual machine after creation in the vSphere Web Client.

Here is an example of a custom workflow that I created called Change Guest OS Type and as you can see that it only shows up under the context of a virtual machine object in the vSphere Web Client. 

From my perspective, the use cases are endless as you can create ANY custom workflow to perform any action or series of operations that can span across VMware products as well as 3rd party systems and directly present them to your end users in the new vSphere Web Client. Not only that, users can specify which workflows they see by default on a given vSphere object and this can differ from user to user based on their daily set of tasks.

So going back to our scenario, here is a way to change the Guest OS and Guest OS Version using a custom vCO workflow.

Step 1 - Download Change Guest OS Type vCO workflow to local desktop.

Step 2 - Open up the vCO Workflow Client, you can do this by pointing your browser to your vCO Server and click on "Start Orchestrator Client" link.

Step 3 - Import the Change Guest OS Type vCO workflow from your desktop to your vCO Server

Step 4 - Next, we need to go to the vSphere Web Client to make this vCO workflow available on a particular vSphere object, in our case it is a virtual machine. On the home page of the vSphere Web Client, click on "vCenter Orchestrator" icon in the center pane or select it from the navigation pane on the left. Once you are in the vCenter Orchestrator configuration page, select the "Manage" tab and click on the "plus" icon.

In this view, you can specify which default vCO workflows are made available across the various vSphere objects. These can be modified or removed based on the frequency of workflow usage.

Step 5 - Locate the Change Guest OS Type vCO workflow on the left hand side and then click on the Add button. Finally, select type to be virtual machine as this workflow is only applicable to a VM and OK to save the settings.

If we take a look at the vCenter Orchstrator configuration page, we will see our new workflow is now listed as one of the defaults for a virtual machine object. You can edit and modify any of these based on the workflows you wish to see by default. I highly recommend you add workflows that you use frequently so you do not have to search through the entire list each time.

Finally, it is time to test drive our new workflow! Locate a virtual machine and right click on the object, in a second you should see a sub-menu for All vCenter Orchestrator Actions and then select our vCO workflow Change Guest OS Type which will start off a very familiar wizard.

The first screen is the object selected, which in our case is our virtual machine. You can of course change this, but we will leave it as it's context was automatically picked up.

The next screen is to select the Guest OS Family (Windows, Linux & Other) that you wish to modify your virtual machine to.

The last part is just to select the Guest OS Version which is provided as a list of the guest OSes based on your previous selection.

To apply the Guest OS change, just click finish and watch the vCO workflow execute.

Though the functionality of changing the Guest OS is not available in the new vSphere Web Client, you can still provide the same functionality to your end users through a custom vCO workflow which are now tightly integrated into the vSphere Web Client. Hopefully this sparks some ideas on other vCO workflows you can create or expose through the vSphere Web Client in your own environment. I know I have a few in mind 🙂

A big thanks goes out to Christophe Decanini for helping me with a few questions while creating this workflow.