During my last post I was trying to restore a demo Wordpress deployment using Velero. The deployment itself was nothing fancy, and was exposed via NodePort instead of an Ingress. The restored app would start as expected but was not accessible with the same NodeIP:NodePort combination that I had from its initial deployment. Here’s my Wordpress manifest (lovingly taken from https://kubernetes.io/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume/): apiVersion: v1 kind: Service metadata: name: wordpress-mysql labels: app: wordpress spec: ports: - port: 3306 selector: app: wordpress tier: mysql clusterIP: None --- apiVersion: v1 kind: PersistentVolumeClaim metadata: name: mysql-pv-claim labels: app: wordpress spec: accessModes: - ReadWriteOnce resources: requests: storage: 20Gi --- apiVersion: apps/v1 kind: Deployment metadata: name: wordpress-mysql labels: app: wordpress spec: selector: matchLabels: app: wordpress tier: mysql strategy: type: Recreate template: metadata: labels: app: wordpress tier: mysql spec: containers: - image: mysql:8.

With Velero now installed on our cluster, we can create a backup job and protect our data. We can also test restores of our data into a new namespace. I mentioned in the previous post that we’re going to use File-System Backups (FSB) for the applications in our TKG cluster, and you’ll see how that’s handled here. Velero works using the idea of “jobs” - either a backup job or restore job.

During my Cloud Director 10.4.1 to 10.5 upgrade, I hit a repeated issue during the database upgrade step. Unable to upgrade the database: org.postgresql.util.PSQLException: ERROR: could not open shared memory segment “/PostgreSQL.839369758”: No such file or directory Or sometimes this: Unable to upgrade the database: org.postgresql.util.PSQLException: An I/O error occurred while sending to the backend I dug through many, MANY logs. At first I thought it was the resources on my VCD cell, so I increased CPU and RAM allocations and the upgrade was successful.

With the release of VMware Cloud Director 10.5 to VMware Cloud Providers, I wanted to jump on it early and get a blog post about the upgrade process and new features. Except, I’ve been battling a small issue getting the upgrade through in my lab! Enjoy the read. My environment consists of: Cloud Director 10.4.1 (single cell) Container Service Extension 4.0.3 App LaunchPad 2.1.2 For this post, I’ll only be upgrading Cloud Director to 10.

Disclaimer: Most of these notes are based on my own internal wiki notes when I deployed Velero in my lab. They may be out of date between the date of publication and when you read it. What is Velero? Velero is VMware’s open-source backup and restore tool for workloads running in Kubernetes. It’s available to anyone for use on Kubernetes, and supports several combinations of integrations with underlying cloud platforms (AWS, Azure, vSphere, etc).

I recently posted how to upgrade VMware Cloud Director’s Container Service Extension from 4.0.1 to 4.0.3. The next step in the journey is to configure the new CAPVCD provider (1.0.1) on any existing Kubernetes clusters deployed by CSE, and then upgrade those clusters from TKG 1.5.4 images to TKG 1.6.1 images. Wait, what am I updating? Kubernetes clusters deployed by CSE include what’s called a Cluster API Provider (CAP) for VMware Cloud Director (VCD) which is where we get CAPVCD.

I’ve got VMware Cloud Director Container Service Extension (CSE) 4.0.1 running in my lab to test and demo Kubernetes Clusters as-a-service in Cloud Director. CSE 4.0.3 was released on the 20th of April 2023 and came with significant improvements. Let’s take a look at my current environment: VCD 10.4.1 CSE UI Plugin 4.0.1 CSE Server 4.0.1 vSphere 7.0U3 NSX-T 4.0.1.1 NSX ALB (Avi) 22.1.2-9086 Based on the above, I don’t need to change a single thing for CSE 4.

With the announcement and release of TKG 2.1, it’s about time I publish a post on deploying TKGm 1.6 in my vSphere lab. /sarcasm If you aren’t familiar with Tanzu Kubernetes Grid (TKG) or, more specifically, TKG Multi-Cloud (TKG-m) then I highly suggest having a read over the official documentation: What is TKG. In a nutshell, Tanzu Kubernetes Grid is a great solution to deploy and manage Tanzu Kubernetes clusters. TKGs is the variation of TKG that is deeply integrated with vSphere (also known as vSphere with Tanzu), while TKGm can be deployed and managed across one or many clouds, including vSphere.

Bill of Materials VMware vRealize Log Insight 8.10.2 VMware Cloud Director 10.4.1 VMware Cloud Director App Launchpad Extension 2.1.2 Photon OS 4.0 (for ALP) Have you deployed the Application Launchpad (ALP) extension into VMware Cloud Director in your Cloud Platform? You’re probably wondering how you can get those pesky logs out from your ALP servers. I found a great post by Vysakh Nair detailing how to use the vRLI Agent to forward logs from Cloud Director appliances.

This one had me stumped for a few minutes. A while ago I was working with a customer that was trying to boot into the EFI shell of a VM. Restarting into the EFI boot menu, they found the EFI shell option was missing: Turns out, you need power off the machine and disable Secure Boot in the VM’s Boot Options: From this To this Booting the machine you’ll find the EFI Shell: