vRealize Operations – Error: Failed to Test adapter instance – Finding Adapter Logs

July 30, 2021VMwareDean

The Issue

I had installed the “VMware vRealize Operations Management Pack for Horizon 1.2” into my vROPs instance, and tried to connect my Horizon instance, instantly hitting the helpful error message of:

Failed to Test adapter instance. Reason - Unknown Error. Please contact support team

Obviously, I’d probably done something wrong, but I didn’t want to just call support for help!

Finding the Cause

So off to find the logs.

In the Administration Tab, scroll down on the left-hand navigation pane to Support
Select Logs
Expand the following folders > /{IP}-MASTER >COLLECTOR>adapters
- Select the correct folder for your adapter type
Click the Log > Click the Blue Go button to load the log

The Fix

As we can see in this environment the issue was quite simple, an illegal character, turns out there was a space in my FQDN.

I correct this and success!

The main reason for this quick blog post, was to show how to find the logs for the adapters so you can troubleshoot things yourself first.

Regards

Follow @Saintdle

Dean Lewis

Resolving VMC – Objects with non-compliant storage policies in SDDC

July 27, 2021VMwarenon-compliant, Storage Policies, VMCDean

The Issue

Overnight I received an email from the VMware Cloud Services platform regarding a VMC environment I am an administrator of. The opening paragraph was as below:

Please be advised that you have VMs and or objects in your VMware Cloud on AWS SDDC that do not comply with the VMC SLA i.e. they have non-compliant storage policies.

Well, this doesn’t sound good. The email trailed off with a list of affected virtual machines and snapshots.

The Cause

This message is a flag on not following best practices in the VMC environment. VMC implements a Managed Storage Policy Profiles (MSPP) which integrate with vSphere VM Storage Policy management into SDDC Management. Ensuring that any workload not assigned a custom storage policy always complies with the services SLA requirements.

In short, if your VMs are part of the managed storage profile, they are covered by the SLAs provided by VMC, and if there’s an outage, you are eligible for credits.

You do have the ability to create your own custom policies as you require, but any VMs that are configured in these policies are not subject to the SLA.

The email is simply a pointer to say “hey we recommend you move those objects to a storage policy covered by the SLA”.

Below we have the custom policy (in this case just the default VSAN policy) and then the provided managed policy which takes the format of “VMC Workload Storage Policy – <Cluster-Name>”

The Fix

If you want to resolve this, then here is a quick PowerCLI script to do that for you.

$custompolicy = <Custom Storage Policy Name>
$managedpolicy = <Managed Cluster Policy Name>

# To target the VMs home configuration
$vms = get-vm * | Get-SpbmEntityConfiguration | where {$_.StoragePolicy -like $custompolicy}

foreach ($VM in $vms) { $VM | Set-SpbmEntityConfiguration -StoragePolicy $managedpolicy}

# To target the hard drives of VMs
$hds = get-vm -location Compute-ResourcePool | get-harddisk | Get-SpbmEntityConfiguration | where {$_.StoragePolicy -like $custompolicy}

foreach ($hd in $hds) { $hd | Set-SpbmEntityConfiguration -StoragePolicy $managedpolicy }

Below we can see now that the VSAN environment is now resyncing the data to the new storage policy requirements.

If you’ve any questions or concerns about the changes to the storage policies for your production workloads, then as always, contact VMware Support to discuss first.

Regards

Follow @Saintdle

Dean Lewis

How to Escape Strings in Terraform with a Dollar Sign ($)

July 14, 2021GeneralCloud Templates (blueprints), dollar sign, escape, interpolation syntax, Invalid character, invalid character error, Terraform, vRA ProviderDean

The Issue

When using Terraform to perform an action, and the input is using a $, you can end up with an output such as the below.

│ Error: Invalid character
│ 
│  on main.tf line 104, in resource "vra_blueprint" "this":
│ 104:      network: '${resource.Cloud_Network_1.id}'
│ 
│ This character is not used within the language.

This happened to me when I was using the Terraform vRA Provider to create Cloud Templates (blueprints) in my vRA environment. The vRA cloud templates use a syntax such as ${input.something}, which clashes with the syntax used by Terraform to identify inputs.

The Cause

Terraform implements a interpolations syntax. These interpolations are wrapped in ${}, such as ${var.foo}.

The interpolation syntax is powerful and allows you to reference variables, attributes of resources, call functions, etc.

The Fix

You can escape interpolation with double dollar signs: $${foo} will be rendered as a literal ${foo}.

Regards

Follow @Saintdle

Dean Lewis

Authenticate Docker to Harbor Image Registry with a Robot Account

July 13, 2021VMware, Kubernetesdocker, Harbor, Image Registry, LoginDean

Just a quick blog post on how to authenticate Docker to a Harbor Image Registry, using a Robot Account, which is good for programmatically access to push/pull images from your registry.

Harbor introduced the capability for administrators to create system robot accounts you can use you run automated actions in your Harbor instances. System robot accounts allow you to use a robot account to perform maintenance or repeated task across all or a subset of projects in your Harbor instance.

In Harbor, to create your robot account, within your project:

Click the Robot Accounts tab
Click New Robot Account
Enter your details as necessary and click save
Select export to file and save the JSON file.

This file will be outputted with a “$” in the name. You can either change the name of the file, or escape the character in the terminal, which I what I’ll be doing below.

Within your terminal run the following commands:

username=$(cat file.json | jq -r .name)
password=$(cat file.json | jq -r .token) <<< See below update
echo "$password" | docker login https://URL --username "$username" --password-stdin

Example
username=$(cat "robot\$veducate.json" | jq -r .name)
password=$(cat robot\$veducate.json | jq -r .token)
echo "$password" | docker login https://harbor-repo.veducate.com --username "$username" --password-stdin

Update October 2021
Since Harbor 2.2 minor release, and I found that within the JSON the key name has changed to secret, so this is the updated example

username=$(cat robot-veducate.json | jq -r .name)
password=$(cat robot-veducate.json | jq -r .secret)
echo "$password" | docker login https://harbor-repo.veducate.com --username "$username" --password-stdin

Now you can pull/push images to your repository using this authentication details.

Regards

Follow @Saintdle

Dean Lewis

Tanzu Mission Control – Using custom policies to ensure Kasten protects a deployed application

July 12, 2021VMware, KubernetesCustom Policies, Kasten, Labels, OPA, Rego, Tanzu Mission ControlDean

The Issue

A while ago I was chatting to Michael Cade, and we pondered the question “How do we ensure Kasten is protecting a newly deployed application in our Kubernetes environment”.

We chatted about how one of the best ways to make your Kasten protection policy flexible is by using metadata labels.

We came up with the simple idea: “What if something forces a known label on the metadata of any applications deployed by our developers in the future?”

This blog post covers this use case using Tanzu Mission Control with custom policies.

The Solution

One of the products we can use to enforce labels on a Kubernetes resource is Open Policy Agent Gatekeeper. Which is an external admission controller which allows you to create policies for the admission of resource creation/changes/updates based on a criteria.

OPA policies are expressed in a high-level declarative language called Rego. (Pronounced “ray-go”.)

Tanzu Mission Control, the fleet management SaaS tool for managing your Kubernetes platforms, provides you the ability to create policies of various types to manage the operation and security posture of your Kubernetes clusters and other organizational objects, implemented by using the OPA Gatekeeper.

Implementing The Solution

For this solution “art of the possible” blog post, we are going to keep it really simple, and implement a policy which covers the following: Continue reading Tanzu Mission Control – Using custom policies to ensure Kasten protects a deployed application →

vEducate.co.uk

Fixing issues and blogging

vRealize Operations – Error: Failed to Test adapter instance – Finding Adapter Logs

The Issue

Finding the Cause

The Fix

Like this:

Resolving VMC – Objects with non-compliant storage policies in SDDC

The Issue

The Cause

The Fix

Like this:

Tanzu Mission Control – Using custom policies to ensure Kasten protects a deployed application

The Issue

The Solution

Implementing The Solution

Like this:

The Issue

Finding the Cause

The Fix

Found this useful? Then share:

Like this:

The Issue

The Cause

The Fix

Found this useful? Then share:

Like this:

The Issue

The Cause

The Fix

Found this useful? Then share:

Like this:

Found this useful? Then share:

Like this:

The Issue

The Solution

Implementing The Solution

Found this useful? Then share:

Like this: