Automation – Page 201

How to configure the vCenter Extension vService using ovftool?

10.01.2014 by William Lam // 9 Comments

A really neat capability that is available in some of VMware's Virtual Appliance is a feature called vCenter Extension vService which leverages the vCenter Solutions Manager and vServices SDK. This feature allows a virtual appliance solution to automatically register itself as an extension with vCenter Server without requiring user to provide vCenter Server connection information and thus simplifying the deployment of a virtual appliance based solution. Some examples of VMware Virtual Appliances that can advantage of this feature are vSphere Replication and vSphere Infrastructure Navigator. If you have deployed either of these solutions, you may have seen a screenshot like the one shown below.

When going through the vSphere C#/Web Client to deploy a virtual appliance that requires vCenter Extension vService, the process is quite simple. You simply click on the drop down menu and select the one and only option as seen in the screenshot above. However, if you are looking to automate the virtual appliance deployment using something like ovftool, you might be asking how do you go about configuring this parameter? This was actually a recent question that I received on an older blog post regarding the automated deployment of vSphere Infrastructure Navigator.

The good news is that ovftool provides a way to configure the vCenter Extension vService using an option called --vService and expected syntax is the following:

--vService:<dependencyId>=<providerId>

To find the dependencyId, you will need to inspect the virtual appliance OVF/OVA. You can simply do this by running ovftool and passing in the OVF/OVA as input. Using the latest vSphere Infrastructure Navigator 5.8 OVA, the dependencyId is simply named "installation" as seen in the VService Dependency section in the screenshot below.

The providerId refers to the vCenter Server and from what I can tell, this statically defined as com.vmware.vim.vsm:extension_vservice

Putting all this together, if you wish to configure the vService, you will need to pass in the following option to the ovftool:

--vService:installation=com.vmware.vim.vsm:extension_vservice

HTML5 console now defaults to HTTPS/WSS in vSphere 5.5 Update 2

09.24.2014 by William Lam // 5 Comments

I just found out from one of my readers that with the latest release of vSphere 5.5 Update 2, the HTML5 Console in vCenter Server now goes over a secure connection (HTTPS) as well as using secure web socket connection (WSS) by default. In addition to this change, the HTML5 console port has also been changed from 7331 to 7343. I know customers have asking about this in the past and though this was not possible with previous releases, I am glad to see that VMware Engineering has now added this capablity, another reason to go to vSphere 5.5 Update 2!

This new change is also documented in the vSphere 5.5 Update release notes, which I some how must have missed:

Virtual machines with HTML 5 console in vSphere 5.5 open connections with http:// instead of https://
When the HTML 5 console is launched on a virtual machine, it uses connections like http:// and web sockets like ws:// instead of secure connections like https:// and wss://.

This release resolves the issue by launching the virtual machine console with secure connection over port 7343 instead of the connection over port 7331.

For those of you using my generateHTML5VMConsole script to generate a pre-authenticated HTML5 VM Console, I have updated the script to include a new variable called isvSphere55u2 which will default to "false" but you can set it in the command-line to "true" and this will automatically generate a URL using HTTPS instead of HTTP and use port 7343 instead of 7331. Other than these two minor changes, the URL format is exactly the same and will continue to work.

Here is a quick screenshot of the HTML5 VM Console URL in my lab running vSphere 5.5 Update 2:

Want to issue a VAAI UNMAP operation using the vSphere Web Client?

09.18.2014 by William Lam // 3 Comments

Recently, I have seen several requests from both customers and partners wanting to be able to run the VAAI UNMAP operation from within the vSphere Web Client. For those of you not familiar with the VAAI UNMAP operation, I recommend you check out this blog post by my colleague Cormac Hogan. Today, the only way to issue the UNMAP operation is by using ESXCLI either remotely or in the ESXi Shell. There is currently not a vSphere API for this operation and therefore it would be difficult to build a native vSphere Web Client Plugin to provide this functionality.

Having said that, one way to provide this capability is through the use of a vCenter Orchestrator (vCO) Workflow which can remotely execute an ESXCLI command whether that is going through ESXCLI using a Linux jump box or through PowerCLI using a Windows jump box. Starting with vSphere 5.5, you can now extend the vSphere Web Client and attach a vCO Workflow to a vSphere Object and be able to execute the workflow right from the vSphere Web Client. This is great if you are already using vCO, but for those that are not, it can be somewhat complex to setup along with a steep learning curve depending on your experience.

Today, there was an exciting announcement from my Automation buddy, Alan Renouf for a new VMware Fling called PowerActions for the vSphere Web Client. This new Fling allows you to easily extend the vSphere Web Client in the following ways:

Access a PowerCLI console directly in the vSphere Web Client
Ability to run a context aware PowerCLI script directly from the vSphere Web Client

The prerequisite for setting up PowerActions is no different than vCO calling a PowerCLI script, you just need a Windows "jump-box" that has PowerCLI installed along with PowerActions. The added benefit, is that you do need to setup another piece of infrastructure like vCO if you are not already using it. This made setting up PowerActions extremely easy to setup and even I was able get it up and running in under 5minutes (minus a quick RTFM moment :)).

Given the number of inquiries regarding VAAI UNMAP operation via the vSphere Web Client, I thought that would be a great use case for my first PowerActions script! Below are the instructions on creating the VAAI UNMAP script for PowerActions:

Step 1 - Click on the PowerCLI Scripts option on the left hand side of the Object Navigator and then click on the "New Script" Icon. Select Datastore as the context aware object for the script.

Step 2 - Provide a name and description for the script. Also make sure to select "Action".

Step 3 - Copy and paste the following script from https://github.com/lamw/vghetto-scripts/blob/master/powershell/unmap-poweraction.ps1 inside the script window and then save the script. What the script does is takes the Datastore object and retrieves a list of ESXi hosts that has access to the Datastore and then randomly selects one of the host. This is required because ESXCLI operations on a per host level and we use that information to pass into Get-EsxCli cmdlet to issue the VAAI UNMAP operation.

Step 4 - To test the script, you just need to right click on a VMFS Datastore and click on PowerCLI->Execute a Script

Note: Please be aware of the impact when running a UNMAP operation, you may want to run this on a non-production datastore for testing purposes or during off hours when your workload may not be as busy.

Step 5 - Select the VAAI UNMAP script you just created and once selected and you will be prompted to specify the number of VMFS blocks to unmap per iteration which is exactly the same input when manually ESXCLI.

At this point, if everything was successful the VAAI UNMAP operation should begin and you can tail /var/log/hostd.log to see the UNAMP operation. Once completed, you should see the prompt return true.

As you can see, it was extremely easy to create my own PowerAction script that expose new functionality and making it available within the vSphere Web Client. I think this is going to be a pretty popular Fling and remember if this is something you would like to see officially in the product, be sure to leave a comment on the PowerAction for vSphere Web Client Fling page, product managers are listening! The only feedback I have is that I would love to see this get extended beyond just PowerCLI and into a generic script extension framework, just imagine the possibilities!