WilliamLam.com

How to create a custom Tanzu Kubernetes Grid (TKG) Node OVA based on Photon OS Real Time Kernel?

by // Leave a Comment

One really cool feature of Tanzu Kubernetes Grid (TKG) is the ability to bring your custom images (BYOI) which can then be used to deploy TKG Workload Clusters. To do so, customers will need to use Kubernetes (K8s) Image Builder tool to author new OVA images and then make TKG aware by updating the Tanzu Kubernetes Release (TKR) Build of Materials (BOM) configuration.

I had played around with Image Builder awhile back during the TKG 1.2 release and it definitely was not very easy to use. I have been meaning to kick the tires on Image Builder again as I know with the latest 1.3.x release, there have been a number of improvements. This week I saw an inquiry from my buddy Alan Renouf who was looking to see if there was a way to use the new Photon OS Real Time Kernel as a base image for a K8s-based application that he was working with that had requirements for the real time kernel.

Interestingly enough, there was another inquiry with a similiar customer request for their edge deployment and I thought this would be a good opportunity to try out Image Builder again, which has been overhauled and the build process can be completely consumed as a Docker container, which definitely made things much easier than before. I also had never played with real time version of Photon OS, so this gave me a reason to try that out which was initially introduced with Photon OS 4.0 but it also looks like real time kernel was added to 3.0 recently, which is the version I had used to test.

Note: vSphere with Tanzu currently does not support the ability to bring your own image like TKG, I know this is something that has been asked about and is being considered in the future.

The BYOI process for TKG is comprised of two steps:

  • Create Custom TKG OVA
  • Update TKG with new TKR BOM

Although there are detailed documentation for this process, I still ran into a number of issues which I think the documentation could be improved with a complete working example rather than using generic values which lead to some interpretation, which I did not interpret correctly the first time through. After posting some questions in the Image Builder Slack Channel, I was able to finally connect the dots with the help from Scott Rosenberg, who I also knew, as a customer of our VMware Event Broker Appliance (VEBA) Fling. Putting everything together, I figure it would be useful to document the process I took and hopefully this can benefit other customers looking to build and consume their own OVA images with TKG.

[Read more...]

VMware Event Broker Appliance (VEBA) v0.6.1

by // Leave a Comment

It has only been about two months since our jammed packed v0.6 release of the VMware Event Broker Appliance (VEBA) solution but the adoption and feedback has been extremely well received by our community. Within the first week or so, we already had a number of folks who had successfully deployed the new version and we started to see new feature enhancements as well as a couple of defects which were quickly resolved. In addition to working through the Github Issues, the team also spent quite a bit of time on creating  more example functions demonstrating how easy it is to author new Knative functions for VEBA across a number of different scripting and programming languages.

Today, we are excited to share a quick update with the release of VEBA v0.6.1 which is a dot release, but it certainly contains several new features that we believe the community can benefit from. For full change log, please refer to v0.6.1 release notes

Here are a few of the new highlighted features:

[Read more...]

Quick Tip - How to check password expiry for a specific vSphere SSO user?

by // Leave a Comment

The default password expiry for vSphere Single-Sign On (SSO) users within the vCenter Server Appliance (VCSA) is 90 days and this of course be changed to match your organizations policy. Although the vSphere UI can remind you right before your password expires, you may want to manually check or proactively inventory this information periodically.

To do so, you will need to SSH to the VCSA and use the dir-cli command with --level 2 option to get additional details for a given vSphere SSO user as shown in the example below:

/usr/lib/vmware-vmafd/bin/dir-cli user find-by-name --account william --level 2
Account: william
UPN: william[a]VSPHERE.LOCAL
Account disabled: FALSE
Account locked: FALSE
Password never expires: FALSE
Password expired: FALSE
Password expiry: 8916 day(s) 2 hour(s) 39 minute(s) 30 second(s)

In this particular environment, I have the vSphere SSO password expiry configured to 9000 days and as we can see for this user, there is ~8916 days left before the password expires.

For those looking to automate this, it looks like this is currently only possible using dir-cli but I have submitted a feature request to the recently released PowerCLI vSphere SSO Module to see if this information can also be included in the Get-SsoPersonUser cmdlet. If you need to retrieve the current configured vSphere SSO password expiry, you can use ldapsearch command within the VCSA or the Get-SsoPasswordPolicy cmdlet.