Skip to content

Dispatches

Introducing setup-task: Install Task in GitHub Actions

If you've been using Task (go-task/task) as your task runner and build tool, you've probably run into the same friction I did: getting it installed cleanly inside a GitHub Actions workflow is more annoying than it should be. There's no native support on GitHub-hosted runners, so you end up writing a curl one-liner, hand-rolling a cache step, or copy-pasting boilerplate across every workflow in every repository. It works, but it isn't great.

tenthirtyam/setup-task is my solution to that problem. It's a purpose-built GitHub Action that handles downloading, caching, and configuring Task in a single step, so the rest of your workflow can get on with running tasks.

Announcing the v2.0.0 Release of the Packer Plugin for VMware Desktop Hypervisors

I'm happy to announce the v2.0.0 release of vmware/packer-plugin-vmware.

This one isn't incremental. It's the result of months spent refactoring, modernizing, and refocusing the plugin.

It's also the first release since the project moved to Broadcom under the vmware GitHub organization.

🚀 Narrowing the Plugin's Focus

The biggest change is scope. The plugin now targets only the VMware Desktop Hypervisors: VMware Fusion Pro and VMware Workstation Pro.

For a long time, the plugin carried the maintenance burden of supporting VMware ESX. That made sense once. It doesn't anymore. Broadcom provides the Packer Plugin for VMware vSphere vmware/packer-plugin-vsphere which is purpose-built for vSphere environments. Keeping parallel ESX support here confused users and split development effort across two plugins. Dropping it means the work goes into the desktop hypervisor experience.

Support for Workstation Player, which has reached end of availability, is gone too.

Everything else in this release builds on that narrower scope.

✨ Enhancements

The release introduces some highly requested features.

Transfer of the Packer Plugins to from HashiCorp to Broadcom

The development and maintenance of the following Packer plugins have been transferred from HashiCorp to Broadcom under the github.com/vmware organization as of January 27, 2026 🥳 🎉

You don't need to change your configurations. Plugin initialization automatically redirects from github.com/hashicorp/packer-plugin-vmware to github.com/vmware/packer-plugin-vmware. We do recommend updating the packer block to source from vmware/ instead of hashicorp/.

Over the past few years, Broadcom has established a valuable partnership with the Packer team at HashiCorp, and we're grateful for their contributions and continued guidance.

Going forward, we're committed to:

  • Continuing development: We'll keep investing in the plugins with new features and improvements.

  • Maintaining stability: We'll keep working on stability and reliability for your image automation workflows.

  • Community engagement: Your feedback shapes what we work on next, so keep it coming.

As the maintainer for these plugins, I'm excited about this next step and looking forward to working on the plugins with you.

Announcing the Packer Plugin for VMware vSphere v2.1.0

v2.1.1 Release

Please update to v2.1.1 to address the issue observed in issue 651.

I'm happy to announce the v2.1.0 release of vmware/packer-plugin-vsphere.

Here are the highlights:

✨ Enhancements

  • Added support for datastore clusters (datastore_cluster) for virtual machine builds and post-processing.
  • Added datasource (vsphere-virtualmachine) for querying virtual machine information, enabling vsphere-clone to select a template.
  • Added an override (bool) option to the vsphere-template post-processor, allowing the overwrite of an existing template if set to true.
  • Refactored tools_sync_time to ensure more flexible and accurate time synchronization settings for virtual machines.

🐛 Bug Fixes

  • Fixed CD-ROM device removal so devices are removed in a deterministic order.
  • Fixed an issue where hardware configuration wasn't always applied to virtual machines.
  • Fixed IPv6 addresses being double-wrapped in brackets in the SSH communicator, which caused connection failures.
  • Fixed nested hardware virtualization settings so they only apply when explicitly requested.
  • Fixed a compatibility issue in the vsphere-supervisor Jenkins template.
  • Refactored firmware type handling so virtual hardware 20 or later with EFI (and EFI with Secure Boot) gets the correct ACPI motherboard layout.

Using the VMware Cloud Foundation Async Patch Tool with PowerShell

Disclaimer

This content is provided for historical reference and may no longer reflect current guidance or best practices.

The VMware Cloud Foundation Async Patch Tool is a command-line tool that enables you to perform asynchronous patching on a VMware Cloud Foundation instance. This enable you to apply patches that are not part of a VMware Cloud Foundation release but are required to address a specific issue, such as a security vulnerability.

Recently, I was asked to assist a couple customers with automating the process of applying async patches to their VMware Cloud Foundation instance. The customers were already using PowerShell to automate other tasks, including using some of our open source PowerShell modules and wanted to continue using PowerShell to automate the async patching process if possible.

This article provides examples of using the Async Patch Tool with PowerShell. The examples are based on the following:

  • VMware Cloud Foundation with vSAN Ready Nodes (--SKU VCF).
  • Downloading async patches to a jump host.
  • Enabling and disabling async patches for a VMware Cloud Foundation instance.
  • Enabling version upgrades for a VMware Cloud Foundation instance.
  • Applying a hot patch for SDDC Manager.

Enabling Active Directory Federation Services for VMware Cloud Foundation

Disclaimer

This content is provided for historical reference and may no longer reflect current guidance or best practices.

Ever wanted to have a true single sign-on experience with your on-premises VMware Cloud Foundation-based private cloud?

In the Summer of 2020 I spent quite a bit of my spare time digging in and learning adjacent product and cloud technologies. One of the products that landed in my view was Active Directory Federation Services with VMware products.

This blog post provides implementation guidance for integrating the following with Active Directory Federation Services (AD FS) for Single Sign-On based on VMware Cloud Foundation 4.x and VMware Validated Design 6.x.

Reference Design for vRealize Network Insight on Cloud Foundation

Disclaimer

This content is provided for historical reference and may no longer reflect current guidance or best practices.

In the Summer of 2020 I spent quite a bit of my spare time digging in and learning adjacent product and cloud technologies. One of the products that landed in my view was vRealize Network Insight. At the same time, my intent was to eventually include this in a VMware Validated Design / VMware Cloud Foundation general release. While the content that I authored during my exploration was not prioritized for an official release, the design was in an Early Access format for a Reference Design.

As a result, I'm happy to share the reference design that follows the same detailed design approach we use in the VMware Validated Design. The design is authored with the default design objective to support up to 10K virtual machines and 2M flows but can be scaled up, as needed. In addition, the design can support single-region and future expansion to multi-region (or multi-instance) Cloud Foundation.

Shutdown and Startup a vSphere with Kubernetes Workload Domain

Disclaimer

This content is provided for historical reference and may no longer reflect current guidance or best practices.

In the last couple of days I've been doing some testing for a VMware Validated Design 6.0.x deployment which, of course, consumes VMware Cloud Foundation 4.0.x. By now, most have heard of vSphere 7 with Kubernetes and Tanzu Kubernetes Cluster which can be deployed in the design - but do you known how do you gracefully shutdown a workload domain and perform a graceful startup from a cold state?

After quite a bit of testing, I'm happy to share the process that I use to perform the processes.

vRealize Suite Account Expirations and Password Requirements

Disclaimer

This content is provided for historical reference and may no longer reflect current guidance or best practices.

A quick post to share some handy content on the account expidations and password required across vRealize Suite 2019 based on some recent work I've done on the VMware Validated Design 6.0.x release. Enjoy!

Table: Users and Password Expirations

Appliance Version Application User Default Expiration Interactive User Default Expiration SSH User Default Expiration
vRSLCM 8.x admin@local Never root 365 days root 365 days
vRLI 8.x Admin Never root 365 days root 365 days
vROPS 8.x admin Never admin 365 days root 365 days
vRA 8.x N/A N/A root Never root Never
vRNI 5.2 admin@local Never admin@local Never support and consoleuser Never

vRealize Suite Lifecycle Manager 1.2 Ports and Protocols, Feature URLs, and Service Account Privileges

Disclaimer

This content is provided for historical reference and may no longer reflect current guidance or best practices.

Behind the scenes in VMware R&D I have been working closely with the product management and engineering team for vRealize Suite Lifecycle Manager to improve the experience and workflows.

Three questions that I'm often asked are:

  1. What ports and protocols does vRealize Suite Lifecycle Manager use for communications?
  2. What URLs must be accessible by my organization to use some vRealize Suite Lifecycle Manager Features (e.g., My VMware, Marketplace, Product Updates, and the in-product Compatibility Guide)?
  3. What permissions are required for a custom role that can be used as a service account for vRealize Suite Lifecycle Manager to vSphere communications?

Well, you're in luck. I can answer this where the documentation currently falls short.