I’ve expanded my sample IBM Cloud for VMware Solutions API usage to demonstrate how you can remove NFS storage, hosts, clusters, and VCS instances dynamically.
See the sample script on Github.
I’ve expanded my sample IBM Cloud for VMware Solutions API calls to demonstrate how you can add file storage dynamically to clusters in your vCenter Server (VCS) instance.
See the sample API invocation on Github.
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:
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:
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.
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.
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:
See also: managing SoftLayer VPN subnet access.
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:
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:
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.
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.
My favorite swag from VMworld 2016 is my Ansible hat. Thanks, RedHat!
full◦valence 