PowerCLI

Getting started w/the new PowerCLI 6.5.1 Get-VsanView cmdlet

04/21/2017 by William Lam 1 Comment

One of the things that I am most excited about from an Automation standpoint with the vSAN 6.6 release is that customers using PowerCLI will now have complete access to the vSAN Management API which we had initially introduced back in vSphere 6.0 Update 2. In PowerCLI 6.5R1, customers only had access to high level vSAN cmdlets which did a pretty good job covering the broad set of vSAN functionality. However, it did not expose the complete vSAN Management API and this has been something many customers have been asking about.

With the new PowerCLI 6.5.1 release, a new Get-VsanView cmdlet is now available that will exposes the complete vSAN Management API using PowerCLI. Since the vSAN Management API has been around since vSphere 6.0 Update 2, you will also be able to use this new cmdlet against a vSAN 6.2, vSAN 6.5 and vSAN 6.6 environment! You simply just need to update your PowerCLI installation which you should always do to get the latest fixes and enhancements.

When you connect to either a vCenter Server and/or ESXi host, you will be able to view all available vSAN Managed Objects for the system by simply running the cmdlet without any arguments as shown in the screenshot below.

If you wish to access a specific vSAN Managed Object type, then you will need to pass in the vSAN MoRef ID from the given list. Here is an example of accessing the "VsanVcClusterHealthSystem-vsan-cluster-health-system" which will give us access to the VsanVcClusterHealthSystem.

SMART drive data now available using vSAN Management 6.6 API

04/19/2017 by William Lam 1 Comment

One of the major storage enhancements that was introduced in vSphere 5.1 as part of the new I/O Device Management (IODM) framework was the addition of SMART (Self Monitoring, Analysis And Reporting Technology) data for monitoring FC, FCoE, iSCSI, SAS protocol statistics, this is especially useful for monitoring the health of an SSD device. Historically, there was not a public vSphere API to consume this information and customers had to rely on ESXCLI which is not very friendly from a programmatic standpoint.

One of the nice enhancements that was introduced in vSAN 6.6 from an API standpoint is that you can now access SMART data using the vSAN Management 6.6 API. The other really cool thing about this enhancement is that although this API was added under the vSAN Management API, you do not actually have to be using vSAN to be able to use this new API!

There are two methods in which you can access the SMART data:

vCenter Server - When connecting to a vCenter Server, you can access the VsanQueryVcClusterSmartStatsSummary() method which is available as part of the VsanVcClusterHealthSystem and you simply just provide it the name of a vSphere Cluster.
ESXi Host - When connecting directly to an ESXi host, you can access the VsanHostQuerySmartStats() method which is available as part of the HostVsanHealthSystem.

To demonstrate how these two new APIs work, I have create two sample scripts: vsan-smarts-data-sample.py using vSAN Management SDK for Python and VSANSmartsData.ps1 using the new PowerCLI Get-VsanView cmdlet.

Here is an example of running the python sample:

python vsan-smarts-data-sample.py -s 192.168.1.200 -u '*protected email*' -p 'VMware1!' -c VSAN-Cluster

Here is an example of running the PowerCLI sample:

Get-VSANSmartsData -Cluster VSAN-Cluster

New vSAN Management 6.6 API / SDKs / CLIs

04/18/2017 by William Lam 2 Comments

With all the new awesome capabilities that have been introduced in vSAN 6.6, there is just as much Automation goodness that will be available for our customers to consume to help them easily mange and operate at scale.

vSAN Management 6.6 API

Below are all the new Managed Objects that have been introduced in the new vSAN Management 6.6 API. This does not even cover all the new methods or object types. For the complete list of vSAN 6.6 APIs, be sure to check out the vSAN Management 6.6 API Reference Guide here.

VsanVcsaDeployerSystem – Virtual Center Service Appliance deployment APIs onto vSAN datastore, operating at both vCenter Server and ESXi Host sides
VsanVdsSystem – vSAN system optimized VDS related operations, especially migrations from VSS to VDS
VsanUpdateManager – VIB installation engine operating at vSAN cluster level (optimized for vSAN clusters)
VsanCapabilitySystem – APIs to query vSAN capability, available on both vCenter and ESXi
VsanMassCollector – vSAN system management query API's to access data and managed object properties, operating at a vSAN Cluster level in vCenter Server only
VsanPhoneHomeSystem – vSAN online health related query API, operating at a vSAN Cluster level in vCenter Server only

How to determine when a Virtual Machine is ready for additional operations?

04/04/2017 by William Lam 3 Comments

This might sound like a pretty simple and basic question, right? However, the answer will actually depend on what you are trying to do. The motivation for this blog post actually stemmed from a conversation I had with one of our Engineers who works over in our core Platform Management Infrastructure which includes VMware Tools, Guest OS Customization, Guest Operations, etc. Although I was aware of some of these methods in determining when a VM was ready, I came to learn about a few new other methods that I was not aware of before. This is really one of the things I love about my job, constantly learning new things and diving deeper into our technologies and sharing that back with our customers to help enable them and their business.

So, what does it even mean for a Virtual Machine to be "ready"? Is it when the VM is powered on? Is it when the VM obtains an IP Address? Is it when the GuestOS is fully customized or is it when I can SSH or RDP to the system? Depending on what you are trying to accomplish, the answer will vary. In addition to that, there are two distinct VM states to consider. The first being the actual Virtual Machine state and the second being the GuestOS state.

Virtual Machine State

The VM state is pretty straight forward, it describes the "Hard" power state of the VM which can either be powered on, powered off or suspended. As you can probably guess, you will need to make sure the VM is powered on before you attempt to check whether the GuestOS is ready 🙂

Using the vSphere API, you can find the VM powerState under:

VirtualMachine->Runtime->powerState

Here is a PowerCLI snippet using the out of box cmdlet to get the power state for a VM named "air":

Get-VM -Name air | Select PowerState

Here is a PowerCLI snippet that uses the vSphere API via Get-View to retrieve the exact same information:

$vm = Get-View -ViewType Virtualmachine -Property Name,Runtime -Filter @{"name"="air"}
$vm.Runtime.PowerState

Exploring new VCSA VAMI API w/PowerCLI: Part 10

03/14/2017 by William Lam 1 Comment

In Part 10, we are going to take a look at local user management for the VAMI interface. By default, only the root local user exists but customers have the option of creating additional accounts. In vSphere 6.5, the VAMI has been enhanced to support different roles such as Admin, Operator and SuperAdmin. You can refer to the VAMI documentation on what each of the roles provides.

VAMI UI Area of Focus

There is not a VAMI UI for user management, this is currently only available using the VAMI REST APIs.

VAMI APIs Used

GET /appliance/techpreview/localaccounts/user
POST /appliance/techpreview/localaccounts/user
DELETE /appliance/techpreview/localaccounts/user/{user-id}

PowerCLI Function

Sample Output

To retrieve all VAMI users, use the Get-VAMIUser function. By default, your system will probably only have the root user unless you have already added additional VAMI users.

To create a new user, we will use the New-VAMIUser which requires a few input parameter that should be pretty self explanatory. The role parameter can be one of three values: admin, operator or superAdmin as defined in the VAMI documentation.

Here is an example of creating a new user called lamw:

New-VAMIUser -name lamw -fullname "William Lam" -role "operator" -email "*protected email*" -password "VMware1!"

If we now re-run our Get-VAMIUser command, we should see the new user that we had just created.

To remove a VAMI user, you simply use the Remove-VAMIUser and specify the name of the user you wish to remove. Below is an example of deleting the user we had just created.

One thing to note is that when using the Connect-CisServer cmdlet to interact with the VAMI REST API, it currently does not support connecting with local VAMI users, only SSO users. This is a limitation with the PowerCLI implementation and does not affect direct use of the VAMI REST API or using it through other SDKs. This is something that will be resolved in a future update of PowerCLI, so something to keep in mind as I was scratching my head when trying to use a local user to authenticate.

PowerCLI module for Proactive HA (including simulation)

03/08/2017 by William Lam 5 Comments

Proactive HA is a very cool new feature that was introduced in vSphere 6.5, which enables our hardware vendors to communicate their hardware specific health information directly into vSphere and specifically with vSphere DRS. This hardware health information can then be leveraged by vSphere DRS to take proactive actions to guard against potential hardware failures. Brian Graf, Product Manager for Proactive HA, DRS and overall vSphere Availability has a nice blog post here where he goes into more details on how Proactive HA works.

As Brian mentioned, a few of our select hardware vendors are already in the process of developing and certifying Proactive HA integrations for vSphere, so stay tuned for those announcements in the future by both VMware and our partners. In the meantime, there was an interesting comment from one of our field folks asking whether it would be possible to "simulate" the new Quarantine Mode operation for an ESXi host to be better understand how this feature might work?

Quarantine Mode is new mode for ESXi, which can only be triggered by Proactive HA. It functions similar to the Maintenance Mode operation, but instead of migrating all VMs off, it will allow existing VMs to continue to run but prevent additional new VMs to be placed on the host.

Proactive HA does provide a set of public vSphere APIs under the healthUpdateManager which is primarily targeted at our hardware vendors to consume. However, these APIs could also be used by our customers to get visibility into the current Proactive HA configuration as well as the health of the ESXi hosts from the Proactive HA provider standpoint. Going back to our initial question, it is possible to "register" a fake Proactive HA provider and manually generate health updates to simulate what a real Proactive HA solution could look like.

Disclaimer: This is for educational and lab purposes only. Creating a fake or simulated Proactive HA provider is not officially supported by VMware, please use at your own risk. The creation of Proactive HA providers as well as publishing health updates is for our hardware vendors to consume which in turn will provide native integrations that include customer visible interfaces within the vSphere Web Client.