Zoom Error 5456000 – An unknown error occurred – Unable to Connect

May 22, 2025General5456000, Error, macos, zoomDean

The Issue

I’ve been plagued with this issue on one single macos device for a while and I’ve not been sure as to why, I’ve tried uninstalling and reinstalling to no avail, and google wasn’t much help.

Ultimately the Zoom app itself couldn’t connect to meetings.

An unknown error occurred
Error code: 5456000

The Cause

I’ve no idea what the exact cause is, however I realised the app had zero network connectivity when it couldn’t even check for updates, even after uninstall and reinstall.

The Fix

Don’t uninstall by moving the app to the trash bin, instead uninstall it this way:

Applications > Zoom > Right Click - Show Package Contents > Click into the Contents Folder > Click into Frameworks > Run the ZoomUninstaller file

Once completed, I’d say it’s a good idea to do a full restart of your macbook, and then reinstall from the latest package downloaded on zoom.us.

Regards

Follow me on Bluesky

Dean Lewis

Safely Clean Up Orphaned First Class Disks (FCDs) in VMware vSphere with PowerCLI

May 15, 2025VMwareCNS volumes, FCD cleanup, First Class Disk, Kubernetes, orphaned disks, PowerCLI, storage cleanup, vmkfstools, VMware, VMware automation, VMware troubleshooting, vSphere, vSphere storageDean

vSphere Orphaned First Class Disk (FCD) Cleanup Script

Orphaned First Class Disks (FCDs) in VMware vSphere environments are a surprisingly common and frustrating issue. These are virtual disks that exist on datastores but are no longer associated with any virtual machine or Kubernetes persistent volume (via CNS). They typically occur due to:

Unexpected VM deletions without proper disk clean-up
Kubernetes CSI driver misfires, especially during crash loops or failed PVC deletes
vCenter restarts or failovers during CNS volume provisioning or deletion
Manual admin operations gone slightly sideways!

Left unchecked, orphaned FCDs can consume significant storage space, cause inventory clutter, and confuse both admins and automation pipelines that expect everything to be nice and tidy.

🛠️ What does this script do?

Inspired by William Lam’s original blog post on FCD cleanup, this script takes the concept further with modern PowerCLI best practices.

You can download and use the latest version of the script from my GitHub repo:
👉 https://github.com/saintdle/PowerCLI/blob/saintdle-patch-1/Cleanup%20standalone%20FCD

Here’s what it does:

Checks if you’re already connected to vCenter; if not, prompts you to connect
Retrieves all existing First Class Disks (FCDs) using Get-VDisk
Retrieves all Kubernetes-managed volumes using Get-CnsVolume
Excludes any FCDs still managed by Kubernetes (CNS)
For each remaining “orphaned” FCD, checks if it is mounted to any VM (even if Kubernetes doesn’t know about it)
Generates a report (CSV + logs) of any true orphaned FCDs (not in CNS + not attached to any VM)
If dry-run mode is OFF, safely removes the orphaned FCDs from the datastore

The script is intentionally designed for safety first, with dry-run mode ON by default. You must explicitly allow deletions with -DryRun:$false and optionally -AutoDelete.

❗ Known limitations and gotchas

Despite our best efforts, there is one notorious problem child: the dreaded locked or “current state” error.

You may still see errors like:

The operation is not allowed in the current state.

This happens when vSphere believes something (an ESXi host, a failed task, or the VASA provider) has an active reference to the FCD. These “ghost locks” can only be diagnosed and resolved by:

Using ESXi shell commands like vmkfstools -D to trace lock owners
Rebooting an ESXi host holding the lock
Engaging VMware GSS to clear internal stale references (sometimes the only safe option)

This script does not attempt to forcibly unlock or clean these disks for obvious reasons. You really don’t want a script going full cowboy on locked production disks. 😅

So while the script works great for true orphaned disks, ghost FCDs are a special case and remain an exercise for the reader (or your VMware TAM and GSS support team!).

⚠️ Before you copy/paste this blindly…

Let me be brutally honest: this script is just some random code stitched together by me, a PowerCLI enthusiast with far too much time on my hands, and enhanced by ChatGPT. It’s never been properly tested in a production environment.

Regards

Follow me on Bluesky

Dean Lewis

Learn KubeVirt: Deep Dive for VMware vSphere Admins

April 28, 2025Kubernetes, VMwareGitOps, Infrastructure as Code, Kubernetes, Kubernetes Networking, KubeVirt, OpenShift Virtualization, Virtualization, VM Migration, VMware, vSphereDean

As a vSphere administrator, you’ve built your career on understanding infrastructure at a granular level, datastores, DRS clusters, vSwitches, and HA configurations. You’re used to managing VMs at scale. Now, you’re hearing about KubeVirt, and while it promises Kubernetes-native VM orchestration, it comes with a caveat: Kubernetes fluency is required. This post is designed to bridge that gap, not only explaining what KubeVirt is, but mapping its architecture, operations, and concepts directly to vSphere terminology and experience. By the end, you’ll have a mental model of KubeVirt that relates to your existing knowledge.

What is KubeVirt?

KubeVirt is a Kubernetes extension that allows you to run traditional virtual machines inside a Kubernetes cluster using the same orchestration primitives you use for containers. Under the hood, it leverages KVM (Kernel-based Virtual Machine) and QEMU to run the VMs (more on that futher down).

Kubernetes doesn’t replace the hypervisor, it orchestrates it. Think of Kubernetes as the vCenter equivalent here: managing the control plane, networking, scheduling, and storage interfaces for the VMs, with KubeVirt as a plugin that adds VM resource types to this environment.

Tip: KubeVirt is under active development; always check latest docs for feature support.

Core Building Blocks of KubeVirt, Mapped to vSphere

KubeVirt Concept	vSphere Equivalent	Description
`VirtualMachine` (CRD)	VM Object in vCenter	The declarative spec for a VM in YAML. It defines the template, lifecycle behaviour, and metadata.
`VirtualMachineInstance` (VMI)	Running VM Instance	The live instance of a VM, created and managed by Kubernetes. Comparable to a powered-on VM object.
virt-launcher	ESXi Host Process	A pod wrapper for the VM process. Runs QEMU in a container on the node.
PersistentVolumeClaim (PVC)	VMFS Datastore + VMDK	Used to back VM disks. For live migration, either ReadWriteMany PVCs or RAW block-mode volumes are required, depending on the storage backend.
Multus + CNI	vSwitch, Port Groups, NSX	Provides networking to VMs. Multus enables multiple network interfaces. CNIs map to port groups.
Kubernetes Scheduler	DRS	Schedules pods (including VMIs) across nodes. Lacks fine-tuned VM-aware resource balancing unless extended.
Live Migration API	vMotion	Live migration of VMIs between nodes with zero downtime. Requires shared storage and certain flags.
Namespaces	vApp / Folder + Permissions	Isolation boundaries for VMs, including RBAC policies.

KVM + QEMU: The Hypervisor Stack

Continue reading Learn KubeVirt: Deep Dive for VMware vSphere Admins →

Kubernetes Finalizers: Deep Dive into PVC Deletion

April 23, 2025Kubernetescloud native operations, csi driver pvc issues, finalizers explained kubernetes, kubernetes deletiontimestamp, kubernetes finalizers, kubernetes platform engineering, kubernetes pvc troubleshooting, kubernetes resource deletion, kubernetes troubleshooting guide, kubernetes volumeattachment, pvc deletion kubernetes, pvc protection controller, pvc stuck terminating, vsphere csi driverDean

This article builds upon an old post I wrote many years ago:
Kubernetes PVC stuck in Terminating state. That post covered the symptoms and quick fixes.

This one is for platform engineers and Kubernetes operators who want to understand why resources like PVCs get stuck in Terminating, how Kubernetes handles deletion internally, and what it really means when a finalizer hangs around.

What Are Finalizers and Why Do They Matter?

In Kubernetes, deleting a resource is a two-phase operation. When a user runs
kubectl delete, the object is not immediately removed from etcd. Instead, Kubernetes sets a deletionTimestamp and, if finalizers are present, waits for them to be cleared before actually removing the resource from the API server.

Finalizers are strings listed in the metadata.finalizers array. Each one signals that a
controller must perform cleanup logic before the object can be deleted. This ensures consistency and is critical when external resources (cloud volumes, DNS records, firewall rules) are involved.

metadata:
  finalizers:
    - example.com/cleanup-hook

Until this list is empty, Kubernetes will not fully delete the object. This behavior is central to the garbage collection process and the reliability of resource teardown.

Deletion Flow Internals

Here’s what actually happens under the hood: Continue reading Kubernetes Finalizers: Deep Dive into PVC Deletion →

Kubernetes Scheduling: nodeSelector vs nodeAffinity

April 16, 2025Kubernetesaffinity rules, CKA prep, cloud native, cluster scheduling, Kubernetes, Kubernetes best practices, Kubernetes Labels, Kubernetes node labels, Kubernetes scheduler, Kubernetes tips, Kubernetes training, nodeAffinity, nodeSelector, pod scheduling, YAML configurationDean

When deploying workloads in Kubernetes, controlling where your pods land is crucial. Two primary mechanisms facilitate this: nodeSelector and nodeAffinity. While they might seem similar at first glance, they serve different purposes and offer varying degrees of flexibility.

The Basics: nodeSelector

The nodeSelector is the simplest way to constrain pods to specific nodes. It matches pods to nodes based on key-value pairs. For instance:

spec:
  nodeSelector:
    disktype: ssd

This configuration ensures that the pod is scheduled only on nodes labeled with disktype=ssd.

However, nodeSelector has its limitations. It doesn’t support complex queries or multiple values for a single key. If you attempt to specify multiple values for the same key, like so:

nodeSelector:
  topology.kubernetes.io/zone: us-east-1a
  topology.kubernetes.io/zone: us-east-1b

Only the last key-value pair is considered, effectively ignoring the previous ones. This behavior stems from the fact that YAML maps require unique keys, and Kubernetes doesn’t merge these entries.

Enter nodeAffinity

For more granular control, nodeAffinity comes into play. It allows you to define rules using operators like In, NotIn, Exists, and DoesNotExist. This flexibility enables you to match pods to nodes based on a range of criteria.

Suppose you want to schedule a pod on nodes in either us-east-1a or us-east-1b. Here’s how you’d achieve that with nodeAffinity: Continue reading Kubernetes Scheduling: nodeSelector vs nodeAffinity →

vEducate.co.uk

Fixing issues and blogging