William Lam

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!

How to run Qemu & KVM on ESXi?

09.17.2014 by William Lam // 4 Comments

Last week I was asked whether ESXi could run the KVM hypervisor as a Virtual Machine (often referred to as Nested Virtualization). I personally have not used KVM before or run it on top of ESXi, but I have heard of many folks successfully virtualizing KVM as a Virtual Machine on top of ESXi. I figure since I have already written several articles on Nesting VMware ESXi, Microsoft Hyper-V and Xen on top of ESXi, I might as well also take a look at KVM!

Disclaimer: Nested Virtualization is not supported by VMware, please use at your own risk.

As mentioned already, I have not used KVM before and one thing I wanted to understand before trying to run it as a Virtual Machine is what the difference is between Qemu and KVM as I have heard both these terms used in-conjunction before. I found this post to be quite helpful in helping me understand the differences between Qemu, KQemu and KVM. I recommend a read if you are new to Qemu or KVM like I am.

From the article above, we now see that you can run either Qemu as a standalone system or KVM which is an accelerator that runs on top of Qemu. With this, I will now demonstrate how you can run Qemu as well as KVM as Virtual Machine on top of ESXi. In the example below, I have selected the latest Ubuntu release (14.04.1) to run both Qemu and KVM.

[Read more...]

Quick Tip - Automate the enabling of the Customer Experience Improvement Program (vTelemetry) in VCSA

09.16.2014 by William Lam // 4 Comments

The VMware Customer Experience Improvement Program is a new feature that was introduced with the latest release of vCenter Server 5.5 Update 2 (vCenter Server for Windows & the VCSA). This feature provides the following per the documentation:

If you choose to participate in the Customer Experience Improvement Program (Program), VMware receives anonymous information to improve the quality, reliability, and functionality of VMware products and services. VMware wants to understand better your vSphere deployment and business needs, and improve VMware response to customer requirements. You can choose to participate in the Program for vSphere at any time.

In my opinion, this has been needed for quite some time now. If you have ever installed any consumer based software, there is usually an option that allows customers to provide basic telemetry data back to the vendor so that they can better understand how the product is being used and more importantly leverage that data to help improve the product and features future.

The process of collecting basic telemetry (sometimes also known as phone home) is not a new concept in the Enterprise. In fact, for those of you who manage a storage array, this has been a standard practice for many many years now where every night, the storage array sends back a variety of telemetry data that may include performance information, utilization, logs, etc. to the vendors HQ. This data is then analyzed and the vendor maybe able to sport trends of a potential issue and proactively alert customers to take action before a problem even arises. Michael White has also recently written about the topic here which I recommend a read as well.

There are four categories of data that is being collected:

esxcfg-info.xml
Extension.json
AboutInfo.json
performance-stats.txt

If you wish to learn more about what is being collected and how to view the data before it is sent, please take a look at the documentation here.

One thing I had noticed when deploying the latest VCSA 5.5 Update 2 is that there is now an option to enable the Customer Experience Improvement Program and of course I was interested in automating this configuration as part of my VCSA deployment script.

Taking a look at the logs, I found that there is a new option that has been introduce in /usr/sbin/vpxd_servicecfg called telemtry:

Telemetry data collection modes:
read         : read and return the current status of the collector
enable       : enables the telemetry data collection
disable      : disables the telemetry data collection

To enable the Customer Experience Improvement Program as part of the VCSA setup, you must enable it after vpxd (vCenter Server) has started. Here is the modified VCSA configuration shell script:

#!/bin/bash

echo "Accepting EULA ..."
/usr/sbin/vpxd_servicecfg eula accept

echo "Configuring Embedded DB ..."
/usr/sbin/vpxd_servicecfg db write embedded

echo "Configuring SSO ..."
/usr/sbin/vpxd_servicecfg sso write embedded

echo "Starting VCSA ..."
/usr/sbin/vpxd_servicecfg service start

echo "Configuring VC Telemetry ..."
/usr/sbin/vpxd_servicecfg telemetry enable

If you decide not to enable this feature during the initial deployment or if you have upgraded from an existing vCenter Server, this feature can also be enabled after the fact. To do so, you will need to login to your vCenter Server using the vSphere Web Client and under the Settings tab of your vCenter Server, there is an option to enable or disable the Customer Experience Improvement Program

Note: When enabling or disabling the Customer Experience Improvement Program, a restart of vCenter Server is not necessary.

Hopefully customers will see the benefit and value in joining the VMware Customer Experience Improvement Program and over time, I think you will start to see some really neat benefits for those who participate in this program.