Authenticating with the SoftLayer API using IBM Cloud IAM

Traditionally you authenticate with the IBM Cloud SoftLayer “classic infrastructure” API using a SoftLayer or “classic infrastructure” API key. However, IBM Cloud has introduced support to authenticate with these APIs using the standardized IAM API keys and identities. At one point IBM implemented a method to exchange IAM credentials for an IMS token, but IBM’s Martin Smolny writes more recently that the classic APIs now “support IAM tokens directly.”

I’ve written a brief script to demonstrate this approach. The script first calls the IAM token API to exchange an API key for an IAM token. Then it constructs a SoftLayer API client object that leverages this token for authentication. Note that for the Python SDK, some paths which create an API client will use the XMLRPC API endpoint by default instead of using the REST API endpoint. The XMLRPC API does not fully support IAM-based authentication. The method used in this script leverages the REST API endpoint and transport, which does support IAM-based authentication.

Updated VMware Solutions API samples

It’s been awhile since I first posted sample IBM Cloud for VMware Solutions API calls. Since then, our offering has moved from NSX–V to NSX–T, and to vSphere 7.0. This results in some changes to the structure of the API calls you need to make for ordering instances, clusters, and hosts.

I’ve updated the sample ordering calls on Github. This includes the following changes:

  • Migrate some of the utility APIs to version 2
  • Send transaction ids with each request to aid in problem diagnosis
  • Order NSX–T and vSphere 7.0 instead of NSX–V and vSphere 6.7
  • Restructure some of the ordering code to order a concrete example instead of a random one
  • Use the new price check parameter to obtain price estimates
  • Ensure that the add–cluster path leverages an existing cluster’s location and VLANs

Provisioning and expanding an IBM Cloud VMware instance via API

IBM Cloud for VMware Solutions recently released a set of public APIs. These APIs allow you to use your IBM Cloud API key to perform operations such as:

  • Get information about your vCenter instance, admin credentials, deployment history, clusters, and hosts
  • Verify parameters for ordering a new vCenter instance, cluster, or hosts
  • Order or remove a vCenter instance, cluster, or hosts

I’ve written some sample code demonstrating how you can authenticate with the IBM Cloud APIs using your API key, and how to interact with the IBM Cloud for VMware APIs. Note that these samples only perform order verification, but you can easily extend them to perform actual orders or removals.

A key use case for these APIs is to expand and contract your VMware instance based on utilization or for workload bursting scenarios. With these APIs, you can now fully automate this process.

Spectrum Protect Plus on IBM Cloud

Spectrum Protect Plus on IBM Cloud

IBM Cloud for VMware Solutions recently made available IBM Spectrum Protect Plus as part of our family of VMware offerings. Spectrum Protect Plus provides powerful and easy to use backup and restore capabilities for your VMware infrastructure and workload. It is now the default backup offering for VMware on IBM Cloud, complementing our existing offering of Veeam Backup & Replication.

At the same time, the IBM Cloud architecture team just published our Spectrum Protect Plus on IBM Cloud reference architecture. Read it and the associated references for information on how we have deployed Spectrum Protect Plus, how you should plan and size your deployment, and how to manage it.

Connecting to the IBM Cloud VPN

IBM Cloud offers a VPN service for your account which you can use to access your dedicated IBM Cloud network. The VPN access is available from your browser using a Java applet, but is also available using a standalone VPN application for Windows, Linux, or macOS.

Unfortunately, I’ve found that the version 2.0 update of the MotionPro Plus application for macOS has broken my VPN access. Not only has it lost all of the passwords I had previously saved, but when I do enter my password and attempt to connect to the IBM Cloud, it immediately disconnects.

While we await a fix from Array Networks, it is possible to revert to an older version of MotionPro:

  1. View the macOS Launchpad and find the MotionPro+ icon
  2. Click and hold the icon until it begins to jiggle, then release. Note that this will delete your MotionPro configuration.
  3. Click the X to uninstall MotionPro+
  4. From the Array Networks support site, download the latest Mac OS MotionPro client corresponding to AG-OS 9.4.0.x
  5. Open the disk image and run the MotionPro installer package within the image. The installer will also install some command line tools
  6. Recreate your MotionPro configuration

See also: managing SoftLayer VPN subnet access.

Monitoring your IBM Cloud vSphere servers

The IBM Cloud for VMware Solutions architecture specifies that vSphere (ESXi) servers should be attached to the public network, but should be configured not to enable their own public IP address. This ensures that workloads running on the servers can access the public network as necessary (e.g., using an NSX Edge Services Gateway), but that the hosts themselves cannot be reached over the internet.

When IBM Cloud (a.k.a. SoftLayer) provisions a bare metal server, the default monitoring configuration for that server is to ping its public IP address. This means that by default all of your ESXi hosts are reported by the IBM Cloud infrastructure portal to be down:

servers-down

You can correct this by re–configuring the monitor for each server to test the private IP address rather than the public IP address. Since you cannot change the IP address of a monitor, you will have to remove the existing monitor and create a new monitor for the private IP address.

If you have many bare metal servers in this situation, you’ll want to automate the re–configuration. To help with this, I wrote a Python script to reconfigure your bare metal server monitors. You’ll have to fill in your SoftLayer username and API key, and the script will reconfigure the monitors for all servers that are (1) marked down, and (2) have a monitor configured for their public IP but not their private IP. The new monitor for the private IP will retain the same attributes as the existing monitor for the private IP. Voila:

sl-monitor-fixed

Managing SoftLayer VPN subnet access

The IBM SoftLayer VPN only supports connection to 64 of your private subnets. If you have more than 64 private subnets in your SoftLayer account, you need to switch your VPN’s subnet management from Automatic to Manual, and select the specific subnets to which you want to connect.

The process for selecting subnets in the UI is not simple, especially if your account has hundreds of subnets. The subnets are not sorted, the dialog is small, and the pagination is slow.

VPN

However, it is possible to manage your VPN subnets programmatically using the SoftLayer API. I have created a Python script that allows you to manage your SoftLayer VPN subnet access. The script requires your SoftLayer username, API key, and a list of private IP addresses to which you want to connect. The script locates the subnets in your account that match your selected IP addresses, and assigns exactly these subnets to your SoftLayer VPN account.

You should wait a few minutes after running the script for it to take effect.