Using the vCO-to-WFA database connection

Previously we connected vCenter Orchestrator (vCO) to the NetApp Workflow Automation (WFA) database in order to perform queries against it. By itself this isn’t terribly useful when we are wanting to provide dynamically populated information to vCO workflows that are executing WFA workflows using REST.

The crux of the problem we are trying to address is that when executing a WFA workflow via REST we are not able to pre-determine valid values for inputs like the cluster or storage virtual machine names. The administrator(s) can provide static values, but this is only helpful with a subset of inputs (how frequently do you add a new cluster?). For volumes, which have the potential to be added and removed frequently this would become a burdensome task quickly.

One answer (there are others, which I will post about in the future) is to use the database. When a WFA workflow is executed natively (i.e. from WFA) it uses query based fields to determine those inputs. The data is populated by crafting SQL commands to pull the data form WFA’s cache database.

Read moreUsing the vCO-to-WFA database connection

Connecting vCenter Orchestrator to the WFA database

The last few posts have been describing how to use REST to execute NetApp Workflow Automation (WFA) workflows remotely. The most recent post showed how to use the NetApp Workflow Automation Package for vCenter Orchestrator to execute those workflows by simply calling one vCenter Orchestrator (vCO) workflow.

However, if you followed along in that post you noticed that the data which is dynamically populated in drop downs and lists when executed from WFA is static when executed from vCO. WFA uses it’s database, which is periodically updated from OCUM, to provide real-time information when executing workflows. This includes selecting, and filtering, things like available clusters, storage virtual machines, and other important data when executing WFA workflows from the WFA GUI.

How do we get that information into vCO so that we can provide dynamic, valid, choices to the user who is executing the vCO workflow? Well, it turns out there are a couple of ways, but for this post, and the next one, we are going to focus on connecting vCO to the WFA database. In the future we will also include another way, using REST to query WFA finders.

This post will focus on connecting vCO to the WFA database and executing basic queries. The follow-on post will show how to integrate those queries into vCO workflows.

Read moreConnecting vCenter Orchestrator to the WFA database

Using the NetApp OnCommand WFA package for vCO

The last two posts have shown some interesting possibilities regarding integration between VMware’s vCenter Orchestrator (vCO) and NetApp Workflow Automation (WFA), however both methods were rather cumbersome. Having to write 100+ lines of javascript in a vCO scriptable task is not exactly convenient!

Fortunately, NetApp has published a vCO package which abstracts all of that code into a handful of workflows and actions easily consumed by vCO workflows. To execute a WFA workflow from vCO you only need to know the name of the WFA workflow and the inputs needed.

The package is available from the NetApp Communities here. Once you have downloaded the package, installation is easy, simply import it into your vCO instance using the GUI. You will need to do a bit of configuration (adding the WFA host name and credentials), but that’s it. Jack has a couple of posts that do an excellent job of describing the setup process on his blog.

wfa_vco_pkg_1

Read moreUsing the NetApp OnCommand WFA package for vCO

Executing WFA workflows from vCenter Orchestrator using REST

In the previous post I showed how to execute a NetApp OnCommand Workflow Automation (WFA) workflow using the REST cmdlets available in Powershell version 4. However, any language or platform can be used for execution via REST, including VMware’s vCenter Orchestrator (vCO).

For the most simple execution we can simply add the WFA host as a REST host to vCO. When the REST plug-in is added to your vCO instance, it adds some helper workflows for managing the connected hosts. Let’s start by executing the “Add a REST host” vCO workflow (located at Library->HTTP-REST->Configuration).

Read moreExecuting WFA workflows from vCenter Orchestrator using REST

Executing WFA workflows using REST

NetApp’s Workflow Automation (WFA) tool is a valuable asset for providing easily consumed scriptable tasks to perform nearly any function that storage administrators require.  For administrators who want to get out of the business of doing mundane tasks, like provisioning generic volumes, adjusting volume sizes, etc., WFA gives you the ability to surface those operations to storage consumers and have them do the work for themselves.

WFA can also play a part in a larger scheme of workflows that can be orchestrated by other software, for example VMware’s vCAC, Puppet, Chef, Microsoft Orchestrator, etc.  This leaves the power (and details) of how to automate the task with the storage team, but enables the IT organization to leverage storage resources in a programmatic manner.  This is done using the REST interface.

Read moreExecuting WFA workflows using REST

SSH to Clustered Data ONTAP using Key Authentication

This post is an update to the earlier post on key based authentication to a ONTAP 7-mode (or ONTAP 7) system. Clustered Data ONTAP’s authentication mechanism is different because it isn’t tied to each node, but rather the cluster itself.

To configure key based authentication for the cluster admin user, you will need to add the authentication method first:

Note that the above warning will occur after executing the command to warn you that a public key must be imported for the user before it can be used. Import the key using the following command:

Note that the -publickey option has double quotes around the public key text, and the key type prefix (ssh-rsa in this case) remains.

Doing this for Storage Virtual Machine admins/users is the same process, just change the appropriate options (-vserver and -username) to valid values.

Also note that you can have multiple keys (up to 99) for an individual user. If you want to enable the entire storage team to access the cluster admin account without having to worry about shared passwords or shared certificates, that is possible.

Clustered Data ONTAP Snapmirror – Removing a relationship from the source

Encountered a situation where the Snapmirror destination had been removed without properly cleaning up the source. This was on a clustered Data ONTAP 8.2 system where I could not delete a volume because of the Snapmirror relationship. This operation is performed from the source, so snapmirror show does not show any relationships (remember…snapmirror is managed from the destination).

Here is what I did to remove the Snapmirror snapshot and the relationship. First, show the destinations:

Once this information is available, you can simply call the snapmirror delete command with the above information to remove the relationship from the source:

The use of -force may be necessary if the destination is not reachable (check cluster peer show for peer status).

NetApp Virtual Storage Console Default Provisioning and Cloning Settings

As a VMware administrator, if you aren’t using Virtual Storage Console (it’s free!) to assist with administering your NetApp storage, you’re missing out on a great tool. It simplifies a lot of tasks through abstraction and a GUI. That being said, I know not everyone has that advantage, especially if you work for an organization where silos are still alive and well.

In order to facilitate best practices when it comes to creating datastores, whether FC/iSCSI LUNs or NFS, I want to publish the settings that VSC uses to create the volumes. As a VMware administrator, you can approach the storage team and ensure the volumes/LUNs/etc. are configured in this manner, or as the storage administrator this is the baseline for VSC configures them.

Remember that these are best practices / recommendations only. They ALWAYS come with the “it depends” caveat…every setup is different, so not all of these may be appropriate for you and your environment.

All of these settings are documented in the VSC Installation and Administration Guide. Additionally, justification and rationale can be found in TR-3749 and TR-4068, the two best practices guides for using vSphere and NetApp together.

Read moreNetApp Virtual Storage Console Default Provisioning and Cloning Settings

Changing the vCenter 5.5 Appliance Hostname

How to change the hostname of the vCenter appliance, including updating the self-signed SSL certificates…

  1. Log into the administrative web page for your appliance using your browser of choice. https://your.vcenter.appliance.ip:5480.
    vca_rename_1
  2. Browse to the Network -> Address tab. Update the hostname and click “Save Settings”.vca_rename_2
  3. Browse to the Admin tab. Toggle the “Certificate regeneration enabled” option to “Yes”.vca_rename_3
  4. Browse to the System tab, click the Reboot button.vca_rename_4
  5. Wait. Wait some more. Keep waiting. Ok, connect to the ESXi host directly and open the console. See…it’s still rebooting. (Why do ESXi and the VCA take so long to boot/reboot?)
  6. Once it’s back, log into the admin interface, browse to the Admin tab and ensure that the “Certificate regeneration enabled” option is set to “No”.

That’s it…simple, but a little time consuming. Any plugins (NetApp Virtual Storage Console, VMware Update Manager, etc.) may need to be re-registered with vCenter to ensure they are working correctly.

Linux Console Scrolling

A simple, but extremely useful, tip…I didn’t know about it for a long time, but now that I do it’s quite helpful.

In most linux consoles, including RHEL and it’s derivatives, SUSE, and Ubuntu (these are the ones I’ve tried) you can scroll up and down to view the console history by holding the Shift key and using Page Up/Page Down.

Unfortunately, it does not work with the cDOT console.