WilliamLam.com

Quick Tip - Auditing configured Per-VM EVC (Enhanced vMotion Compatibility) 

by // Leave a Comment

A request came in last week to help automate the inventory of vSphere Virtual Machines (VMs) that have been configured with the Per-VM EVC (Enhanced vMotion Compatibility) capability.


It is important to understand that if a VM is not configured with Per-VM EVC, it will automatically inherit the configured EVC-mode from the vSphere Cluster. While there are several vSphere API properties that will give you information about the EVC details for a VM, the quickest way to check whether a VM has Per-VM EVC configured is by looking at the FeatureMask property.

Here is a quick PowerCLI snippet that demonstrates the use of this vSphere API:

$vms = Get-View -ViewType VirtualMachine -Property Name, Runtime

foreach ($vm in $vms) {
    if($vm.Runtime.FeatureMask -ne $null -and $vm.name -notmatch "vCLS-") {
        Write-Host "Per-VM EVC Enabled for $(${vm}.name)"
    }
}

Here is an example output when running this script and you can adjust the output based on your needs including exporting it to CSV list/etc.

Quick Tip - Configuring vSphere Kubernetes Service (VKS) Cluster with self-signed container registry

by // 1 Comment

Over the weekend, I had finished building a small container application that I had developed on my local desktop, which worked great. However, the real test was to deploy the application on a vSphere Kubernetes Service (VKS) Cluster, which would require the container image to be hosted in a container registry.

Rather than using a public container registry, like many organizations, you typically would setup an internal registry that your infrastructure could have access to. Harbor is my go to container registry and is extremely simple to setup as it uses docker-compose under the hood.

After uploading my container image to Harbor, if you try to deploy it to your VKS Cluster, you will immediately see the following image pull error:

tls: failed to verify certificate: x509: certificate signed by unknown authority


Just like any system that attempts to connect to an endpoint with a self-signed TLS certificate that it can not verify, it will not trust which is the default behavior.

For our VKS Cluster to be able to successfully pull an image from Harbor with a self-signed TLS certificate, we need to add the trusted CA to our vSphere Namespace and then reference that as part of our VKS Cluster deployment.

[Read more...]

MS-A2 VCF 9.0 Lab: Configuring External IdP for Multiple VCF Automation Organizations

by // Leave a Comment

This post is part of a short series that builds on our minimal VMware Cloud Foundation (VCF) 9.0 deployment (2x Minisforum MS-A2) and showcases how to fully leverage the exciting new capabilities in the VCF 9 platform, all while maintaining a minimal resource footprint, which is ideal for lab and learning purposes.

In this blog post, we will walk through the setup of connecting a VCF Automation (VCFA) Organization to an external identity provider (IdP) using a free and self-hosted solution called Keycloak, which I am also using for setting up VCF Single Sign-On (SSO) capability. Depending on your goals for your VCFA lab environment, the ability to explore different IdP policies (e.g. MFA, etc) for an organization to experimenting with VCFA roles and access controls, will ultimately depend on the capabilities of your IdP


Since I am using Keycloak as my IdP, I can create what is known as a realm, which allows me to manage a collection of users and groups. From a single Keycloak Realm, I can then create multiple OIDC Application Clients that can then be used to provide authentication to both my VCFA Provider Admin Portal (via VCF SSO) as well as to the different VCFA User Organizations as depicted in the visual below, all backed by a single realm.


Keycloak allows customization of the IdP login screen, which is a pretty common feature of most IdP. For Keycloak specifically, the login customization is defined on per-realm basis, so you would need to create multiple realms that would then contain an OIDC Application Client for your desired VCFA Organizations which is depicted in the diagram below.


For MFA policies such as mandating a second factor or enforcing passkeys (YubiKey, Apple FaceID, Apple TouchID, etc), while these can be defined at a realm-level, you can override this on per OIDC Application Client. The above illustration is purely for simple lab setup, you can certainly setup a more complex environment with different IdPs that is connected to each VCFA Organization which will closely mirror environment like a Cloud Service Provider (CSP) than a typical Enterprise who might only have a single IdP.

Note: Keycloak has an extensive framework for building custom themes, I am using this KoreUI theme package, which I was able to hack up to build the customization screens you see in the very first screenshot.

Here are some additional VCF Automation IdP Resources that might be of interests if you would like to learn more:

Requirements:

[Read more...]