WilliamLam.com

Using the vSphere API in vCenter Server to collect ESXTOP & vscsiStats metrics

by // 1 Comment

Back in 2013, I wrote two articles here and here on how to use the Service Manager API that was introduced in vSphere 5.1 to remotely collect ESXTOP and vscsiStats metrics. At the time, I was told that this API was only available when connecting directly to an ESXi host using the vSphere API. This was still a huge improvement over the previous method which basically required customers to run the commands locally. For ESXTOP, there was resxtop but it was not available for all platforms and some customers still prefer to use the ESXi Shell's version. When I had learned about this API, I was really hoping I could collect both ESXTOP & vscsiStats metrics using vCenter Server which would remove the need to have direct connectivity to each ESXi host.

Last week, an Engineer came across one of my blog posts related to the Service Manager APIs which helped him with a problem he was trying to solve. In the email conversation, I then came to learn from the Engineer that the the Service Manager API can be used from vCenter Server and going directly to the ESXi host was not necessary. It turns out that the QueryServiceList() method which accepts an array of "location" expects a special keyword prefix appended to the list of ESXi hosts that you wish to use the local Service Manager instances on.

The special keyword prefix is "vmware.host." and this is appended to either the Hostname or IP Address of the ESXi hosts being managed by the vCenter Server. For example, in my environment I have an ESXi host (192.168.1.50) that is managed by my VC and so the location string for that host should be "vmware.host.192.168.1.50". If the method was successfully called, you should get back the two service instances for ESXTOP and vscsiStats for each of the ESXi hosts where you can then perform the metric collection.

I have created two sample pyvmomi scripts which exercises the Service Manager API for ESXTOP and vscsiStats:

Note: For more details on how to use Service Manager API to collect ESXTOP and vscsiStats, please refer to this post here and here.

[Read more...]

Exploring new VCSA VAMI API w/PowerCLI: Part 8

by // 5 Comments

In Part 8, we are going to take a look how services are managed in a VCSA or PSC node which is provided by the vCenter Server Lifecycle Management system also referred to internally as vMon. You can interact with the vMon service using either the service-control utility which is only available via SSH or the VAMI APIs which are available remotely. As you probably have guessed, we will be using the VAMI APIs 🙂

VAMI UI Area of Focus

There is not a service view in the VAMI UI (https://[VCSA]:5480) for either the VCSA or PSC. However, this information is available as part of the VAMI information when logged into the vSphere Web Client by navigating to System Configuration->Nodes->Related Objects or System Configuration->Services.

VAMI APIs Used

  • GET /appliance/vmon/service
  • POST /appliance/vmon/service/start
  • POST /appliance/vmon/service/stop

PowerCLI Function

Sample Output

The Get-VAMIService will lists all available services for the given VCSA or PSC node that you are connected to. It provides the exact same output that you would see in the vSphere Web Client such as the name of the service, the current state, the health and whether the service is disabled or configured to start up automatically or manually.


The function also accepts a name parameter if you know the specific service you wish to query, for example here is the syntax for checking the Auto Deploy service which is named rbd:

Get-VAMIService -Name rbd

We can use the Start-VAMISerivce function and given a service name, we can start it as shown in the screenshot below.


Similialy, we can use the Stop-VAMISerivce function and given a service name to stop the service as shown in the screenshot below.

How to forward other VCSA 6.5 logs to remote syslog server?

by // 6 Comments

As mentioned in my previous article (which I strongly recommend you review before continuing further), the VCSA 6.5 no longer uses syslog-ng as the syslog client and it has been replaced with rsyslog. This means the instructions outlined in my old article here is no longer valid on forwarding logs from a VCSA 6.5 system to a remote syslog server. Luckily, the process to forward logs within VCSA 6.5 is also pretty straight forward using rsyslog.

Disclaimer: This is not officially supported by VMware, please use at your own risk. For very large environments, forwarding additional logs can potentially impact the vCenter Server service, so please take caution in the logs you decide on forwarding and test in a lab environment before applying this across your environment.

To help provide a concrete example, I will be using a real world scenario that often comes up from customers on auditing failed vSphere Web Client login success/failures as well as SSO user creation, deletion and password changes. The following two log files provides us with this information which we will forward to our syslog server:

  • /var/log/vmware/sso/ssoAdminServer.log - Auditing SSO logins
  • /var/log/vmware/sso/vmware-identity-sts.log - Auditing SSO user changes

We will be making using of rsyslog Text File Input Module (imfile) which will allow us to process local log files in the VCSA.

[Read more...]