In years gone by, costing of your technology platforms was covered in a product called vRealize Business for Cloud. Since the move to the 8.x code based, this product was EOL’d.
The main functions where customers saw value, to provide costings for your datacenter and virtual machines, was wrapped up into vRealize Operations.
This blog post is going to deep dive into the costing capabilities within vRealize Operations across your on-premises datacenters, and what happens when you start to consume VMware on Hyperscaler solutions, such as VMware Cloud on AWS (VMC).
Configure the Global Currency Setting
The first action is setting the global currency for the vRealize Operations instance. There are two important things to note when undertaking this configuration:
This can only be set once
This setting cannot be changed once it is set
To configure:
Click on Administration
Click on the Global Settings Tile
Click on the Cost/Price heading
Click to “Set currency”
Select your currency from the list and click “Set Currency”.
You will get a dialog to say the configuration has taken place.
Now below you can see that this setting is in place and there is no button/clickable option to change it.
Configuring Cost Settings
Now that the global currency is configured, we can start configuring all the cost settings for our Datacenter platforms.
I had the pleasure of working with a customer who wanted to use property groups within vRealize Automation, to provide various configuration data to drive their deployments. They asked some queries about how to use property groups that went beyond the documentation, so I thought it would also make a good blog post.
What are property groups?
Property groups were introduced in vRealize Automation 7.x and sorely missed when the 8.x version was shipped. They were reintroduced in vRA 8.3.
When you several properties that always appear together in your Cloud Templates, you can create a property group to store them together.
This allows you to re-use the same properties over and again across Cloud Templates from a central construct, rather than replicate the same information directly into each cloud template.
The benefit of doing this, is that if you update any information, it is pushed to all linked cloud templates. Potentially this could be a disadvantage as well, so once you use these in production, be mindful of any updates to in-use groups.
There are two types of property groups. When creating a property group, you select the type. You do not have the ability to change or convert the type once the group has been created.
Input property groups gather and apply a consistent set of properties at user request time. Input property groups can include entries for the user to add or select, or they might include read-only values that are needed by the design.
Properties for the user to edit or select can be readable or encrypted. Read-only properties appear on the request form but can’t be edited. If you want read-only values to remain totally hidden, use a constant property group instead.
Constant property groups silently apply known properties. In effect, constant property groups are invisible metadata. They provide values to your Cloud Assembly designs in a way that prevents a requesting user from reading those values or even knowing that they’re present. Examples might include license keys or domain account credentials.
Getting Started with a Input Property Group
Ultimately the Input Property Group works the exact same way as Inputs you specify on the cloud template directly. The group option simply provides a way to centralise these inputs for use between cloud templates.
Create an Input Property Group
Click on Design Tab
Click Property Groups from the left-hand navigation pane
In this blog post I’m going to deep dive into the end-to-end activation, deployment, and consuming of the managed Tanzu Services (Tanzu Kubernetes Grid Service > TKGS) within a VMware Cloud on AWS SDDC. I’ll deploy a Tanzu Cluster inside a vSphere Namespace, and then deploy my trusty Pac-Man application and make it Publicly Accessible.
Previously to this capability, you would need to deploy Tanzu Kubernetes Grid to VMC, which was fully supported, as a Management Cluster and then additional Tanzu Clusters for your workloads. (See Terminology explanations here). This was a fully support option, however it did not provide you all the integrated features you could have by using the TKGS as part of your On-Premises vSphere environment.
What is Tanzu Services on VMC?
Tanzu Kubernetes Grid Service is a managed service built into the VMware Cloud on AWS vSphere environment.
This feature brings the availability of the integrated Tanzu Kubernetes Grid Service inside of vSphere itself, by coupling the platform together, you can easily deploy new Tanzu clusters, use the administration and authentication of vCenter, as well as provide governance and policies from vCenter as well.
Note: VMware Cloud on AWS does not enable activation of Tanzu Kubernetes Grid by default. Contact your account team for more information.
Note2: In VMware Cloud on AWS, the Tanzu workload control plane can be activated only through the VMC Console.
But wait, couldn’t I already install a Tanzu Kubernetes Grid Cluster onto VMC anyway?
Tanzu Kubernetes Grid is a multi-cloud solution that deploys and manages Kubernetes clusters on your selected cloud provider. Previously to the vSphere integrated Tanzu offering for VMC that we are discussing today, you would deploy the general TKG option to your SDDC vCenter.
What differences should I know about this Tanzu Services offering in VMC versus the other Tanzu Kubernetes offering?
When Activated, Tanzu Kubernetes Grid for VMware Cloud on AWS is pre-provisioned with a VMC-specific content library that you cannot modify.
Tanzu Kubernetes Grid for VMware Cloud on AWS does not support vSphere Pods.
Creation of Tanzu Supervisor Namespace templates is not supported by VMware Cloud on AWS.
vSphere namespaces for Kubernetes releases are configured automatically during Tanzu Kubernetes Grid activation.
Activating Tanzu Kubernetes Grid Service in a VMC SDDC
Reminder: Tanzu Services Activation capabilities are not activated by default. Contact your account team for more information.
Within your VMC Console, you can either go via the Launchpad method or via the SDDC inventory item. I’ll cover both:
Click on Launchpad
Open the Kubernetes Tab
Click Learn More
Select the Journey Tab
Under Stage 2 – Activate > Click Get Started
Alternatively, from the SDDC object in the Inventory view
Click Actions
Click “Activate Tanzu Kubernetes Grid”
You will now be shown a status dialog, as VMC checks to ensure that Tanzu Kubernetes Grid Service can be activated in your cluster.
This will check you have the correct configurations and compute resources available.
When running the OpenShift-Install CLI tool on my Apple MacBook M1 to create an OpenShift Cluster I kept hitting the same error:
assertion failed [inst.has.value()]: failed to decode instruction: 0x0
The Cause
This is believed to be an issue created with the use of Rosetta 2 and Golang, and is somewhat documented on this GitHub issue by Apple Engineering.
The OpenShift-Install CLI Tool uses Terraform which relies on GoLang.
The Fix
In the above GitHub issue, it is found that running the below command either locally, or keeping it in your ~/.zshrc file will resolve the issue as a workaround.
