WilliamLam.com

  • About
    • About
    • Privacy
  • VMware Cloud Foundation
  • VKS
  • Homelab
    • Resources
    • Nested Virtualization
  • VMware Nostalgia
  • Apple

How to configure Knative and containerd in VMware Event Broker Appliance (VEBA) to use a private registry?

03.29.2022 by William Lam // 2 Comments

I was recently helping out fellow colleague Patrick Kremer who was looking into an issue that one of our users had filed on how to configure the VMware Event Broker Appliance (VEBA) so that it can take advantage of a custom container registry for deploying VEBA functions. If you attempt to specify a container image from a private container registry, especially one that has a self-signed certificate, you will see the following error:

Unable to fetch image "harbor.primp-industries.local/library/veba/kn-py-echo:1.0": failed to resolve image to digest: Get "https://harbor.primp-industries.local/v2/": x509: certificate signed by unknown authority; Get "https://harbor.primp-industries.local:443/v2/": x509: certificate signed by unknown authority

I had assumed that this should have been a pretty trivial configuration change to make the underlying Kubernetes container runtime trust the desired container registry and that there would be an easy to follow tutorial that Patrick could search for. The latest release of VEBA has moved away from using the Docker runtime to containerd and this should have helped narrow down the search results, at least that was our assumption.

Not only are there plenty of resources online, but there seem to be multiple methods depending on the version of Kubernetes and containerd which was pretty overwhelming. After several attempts using various blog articles, Patrick found that the trust error has still not gone away. I finally decided to take a closer look and discovered that there are actually two components that must be updated to properly support a private container registry: containerd & Knative Serving Controller. I eventually found this page in the Knative Serving documentation that provided a hint but ultimately, I was not able to fully grok the details until I came across this Github thread that brought clarity on how to create the required secret for the root CA certificate which would allow the Knative Serving controller to trust the root CA certificate.

Below are the instructions for the required changes and I have also attempted to simplify the steps by providing automation snippets that makes it easy for anyone to consume. In my setup, I am using Harbor registry which was built from my Harbor Virtual Appliance but the steps should apply for any other private container registry.

[Read more...]

Categories // Cloud Native, Kubernetes Tags // Cloud Native Runtime, Harbor, Knative, VMware Event Broker Appliance

How to retrieve the default VM hardware configuration for a specific Guest OS in vSphere?

03.28.2022 by William Lam // Leave a Comment

Have you ever wondered how or where the vSphere UI generates the default Virtual Machine hardware configuration after selecting a specific Guest OS during the VM creation wizard?


The answer is simply by asking the vSphere platform 🙂 and of course this is provided as an API for any client to consume including our own vSphere UI.

This is a topic I had written about back in 2013 here and here, which demonstrates how to use the EnvironmentBrowser API to query for the list of supported Guest OS and Virtual Hardware Compatibility. In addition to this information, we can also ask the vSphere platform on what are the default hardware configuration for all supported Guest OS using the QueryConfigOption API.

[Read more...]

Categories // Automation, ESXi, vSphere Tags // guest os

Quick Tip - How to deploy OVF/OVA to multiple networks using OVFTool?

03.16.2022 by William Lam // Leave a Comment

For automation purposes, customers use the handy OVFTool, which is a multi-platform command-line utility for uploading or exporting OVF/OVA images. During an upload, users would typically specify the --network argument which will assign the desired vSphere Network to the deployed VM and if the VM included multiple network adapters, it would assign the same network which can then be modified during post-deployment.

What if you had a OVF/OVA that included multiple network adapters and you wanted a different network for each adapter? Luckily, this is also supported with OVFTool by using the --nic argument, which expects the network name as codified within the OVF/OVA to tell OVFTool which vSphere Network to assign. You can find OVF/OVA network name by simply running OVFTool command against the OVF/OVA without any arguments and you should see the name as shown in the screenshot below.


Note: The network name in the OVF/OVA MUST be unique to be able to assign different networks during upload.

[Read more...]

Categories // Automation, OVFTool Tags // ovftool

  • « Previous Page
  • 1
  • …
  • 115
  • 116
  • 117
  • 118
  • 119
  • …
  • 561
  • Next Page »

Search

Thank Author

Author

William is Distinguished Platform Engineering Architect in the VMware Cloud Foundation (VCF) Division at Broadcom. His primary focus is helping customers and partners build, run and operate a modern Private Cloud using the VMware Cloud Foundation (VCF) platform.

Connect

  • Bluesky
  • Email
  • GitHub
  • LinkedIn
  • Mastodon
  • Reddit
  • RSS
  • Twitter
  • Vimeo

Recent

  • VMware Flings is now available in Free Downloads of Broadcom Support Portal (BSP) 05/19/2025
  • VMUG Connect 2025 - Minimal VMware Cloud Foundation (VCF) 5.x in a Box  05/15/2025
  • Programmatically accessing the Broadcom Compatibility Guide (BCG) 05/06/2025
  • Quick Tip - Validating Broadcom Download Token  05/01/2025
  • Supported chipsets for the USB Network Native Driver for ESXi Fling 04/23/2025

Advertisment

Privacy & Cookies: This site uses cookies. By continuing to use this website, you agree to their use.
To find out more, including how to control cookies, see here: Cookie Policy

Copyright WilliamLam.com © 2025

 

Loading Comments...