Dispatches¶

Writing Practical Contribution Guidelines for GitHub Repositories

Every open-source project on GitHub eventually reaches the point where someone outside the immediate author wants to help. They open an issue that is missing half the information needed to reproduce it. They submit a pull request on the main branch that touches a dozen unrelated files. Or they send a message asking where to start.

A well-written CONTRIBUTING.md is the answer to all of those situations before they happen. It is the first thing a potential contributor reads when they want to get involved, and it sets the tone for every interaction that follows. Done right, it reduces back-and-forth, keeps the project moving, and signals to contributors that the project is organized and worth their time.

This post walks through how I write CONTRIBUTING.md files for my open-source projects: what goes in them, why each section matters, and how to write guidelines that contributors will actually follow.

Introducing setup-task: Install Task in GitHub Actions

If you have been using Task (go-task/task) as your task runner and build tool, you have 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 is 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 is not great.

tenthirtyam/setup-task is my solution to that problem. It is a purpose-built GitHub Action that handles downloading, caching, and configuring Task in a single step so you can get back to what actually matters: the tasks themselves.

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

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

This isn't just an incremental update; it's the culmination of months of dedicated effort to refactor, modernize, and refocus the plugin for the future.

Additionally, this is the first release of the plugin after the transfer of the project to Broadcom under the vmware GitHub organization.

🚀 Redefining the Plugin's Mission

The first and most significant change is a decision to refine the plugin's focus. Moving forward, the plugin will exclusively target 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. While this was useful in the past, the ecosystem has evolved. Broadcom provides the feature-rich Packer Plugin for VMware vSphere vmware/packer-plugin-vsphere which is purpose-built for vSphere environments. Continuing to maintain parallel ESX support in this plugin created a confusing user experience as well as split or duplicated development focus. By removing it, efforts will be dedicated to creating the best possible plugin experience for the desktop hypervisor user base.

Similarly, support is removed for the Workstation Player which has reached end-of-availability.

This sharpened focus is the bedrock upon which the release is built, enabling a more stable, feature-rich, and maintainable plugin.

✨ Enhancements

The release will introduces some highly requested features that unlock new and more efficient workflows.

Transfer of the Packer Plugins to from HashiCorp to Broadcom

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

• Packer Plugin for VMware vSphere (vmware/vsphere)
• Packer Plugin for VMware Desktop Hypervisors (vmware/vmware)

No changes are required in your configurations and plugin initialization will be automatically redirected from github.com/hashicorp/packer-plugin-vmware to github.com/vmware/packer-plugin-vmware. However, we encourage you to consider updating your configurations to source from vmware/ from hashicorp/ in the packer block.

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

This transition underscores the dedication to the plugin and our commitment to:

• Continuing development: We're eager to invest in the plugin's future, bringing new features and improvements to better serve your needs.

• Maintaining stability: We will continue to iterate to enhance the plugin's stability and reliability for your image automation workflows.

• Fostering community engagement: We highly value your feedback and look forward to collaborating with you on the plugin's evolution.

As the maintainer for these plugins, I'm excited about this next step and the opportunity to further enhance the plugin in collaboration with you.

Announcing the Packer Plugin for VMware vSphere v2.1.0

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

Below are the highlights for the release:

✨ 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

• Addressed issue removing CD-ROM devices from a virtual machine to ensure a deterministic order of removal.
• Addressed issue where hardware configuration wasn't always applied to virtual machines, ensuring consistent hardware settings.
• Addressed issue where IPv6 address were being double-wrapped in brackets in SSH communicator causing connection failures.
• Addressed issue nested hardware virtualization settings to only apply when explicitly requested, preventing unintended configuration changes.
• Addressed issue in the vsphere-supervisor Jenkins template to address compatibility.
• Refactored support for specifying the firmware type when creating and configuring the virtual machines to ensure that the APCI layout for virtual hardware 20 or later with EFI (and EFI with Secure Boot) have the correct APCI motherboard layout.

Using the VMware Cloud Foundation Async Patch Tool with PowerShell

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

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

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

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

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