Dispatches¶

vmcli: A Practical Guide for the VMware Fusion and Workstation Command Line

The command line is still the fastest way to script power state, disks, snapshots, and guest operations on with VMware Fusion (macOS) and VMware Workstation (Windows and Linux).

vmcli ships with both desktop hypervisors so you can drive the same lifecycle steps without opening the GUI.. Same lifecycle steps, no GUI.

This post covers the main modules with copy-and-paste examples.

Always confirm flags on your build with vmcli <module> --help and vmcli <vmx> <module> <command> --help, since Fusion and Workstation revisions do not always stay in lockstep.

Basic Syntax

vmcli is the cross-platform CLI for Fusion and Workstation. Each functional area (power, snapshots, storage, networking, guest operations) is a module with its own sub-commands. The usual shape is:

vmcli <vmx location> <module> <command> [args]

Global Options

Default Install Locations

CI runners and daemons often lack the same PATH as an interactive shell. Point scripts at the real binary when vmcli is not on PATH:

On Linux hosts, resolve the Workstation package path for your distro, or install location, then call that absolute path from automation.

If your host responds with vmcli: command not found, the binary is probably fine, but your PATH needs updating.

JSON Output for Scripting

Several query style commands accept -f json so you can parse output with jq or your language's JSON decoder instead of scraping plain text. Sub-command spelling is case sensitive (query vs Query), so match vmcli <module> --help on your build.

If -f json is missing on a sub-command, fall back to the default text layout or upgrade the desktop hypervisor build.

Core Modules and Commands

1. Power Operations (Power module)

Stop, Suspend, and Reset need -o <opType>; other rows below do not.

Power Start optional flags:

Valid -o opType values for Stop, Suspend, and Reset:

2. VM Management (VM & VMTemplate modules)

To create a new VM, use the VM module. Note that -g accepts a numeric preset and -c accepts any custom guest OS string.

vmcli VM Create -n myVM -d ~/Desktop/ -c arm-ubuntu-64

The VMTemplate module is used for creating and deploying VM templates natively from the command line.

3. Snapshot Management (Snapshot module)

Snapshots give you quick checkpoints for testing and rollbacks. Commands that target an existing snapshot take a <uid> integer. Run Snapshot query first to list UIDs.

!!! warning "Deleting and Reverting Snapshots" The VM must be powered off or suspended before using Snapshot Delete. Always run Snapshot query first to confirm the correct UID.

4. Hardware and Storage (Disk, Ethernet, Nvme, Sata modules)

Disk module. Create, extend, query, and configure virtual disks:

Valid -a adapter types for Disk Create: ide, buslogic, lsilogic (use lsilogic for all other types).

Valid -t disk types for Disk Create:

Ethernet module. Configure virtual network adapters:

Other Hardware Modules:

5. Configuration (ConfigParams module)

Read and write raw .vmx keys (RAM, CPU, nested virt, display name, and many hardware toggles).

Set bios.forceSetupOnce to TRUE for a one-time visit to firmware or EFI setup on the next boot; the hypervisor clears it after that cycle.

6. Shared Folders (HGFS module)

The Host Guest File System (HGFS) module manages the Shared Folders feature between host and guest. VMware Tools must be installed and running in the guest.

On many Fusion vmcli builds, HGFS sub-commands use the .vmx slot label (sharedFolder0, sharedFolder1, …), not an arbitrary string. Create the slot with SetPresent sharedFolder0 true (or matching ConfigParams entries), then set host path, guest name, and ACLs. Arbitrary labels such as projects alone are rejected until that slot exists.

7. Guest Operations (Guest module)

The Guest module executes operations directly inside a running VM. VMware Tools must be running for guest-side calls. Commands that start programs or touch the filesystem need -u <username> and -p <password>. Guest query omits -u / -p on supported builds, but the VM must still be powered on (offline returns an error). Confirm with vmcli <vmx> Guest query --help on your SKU.

8. VMware Tools (Tools module)

9. Other Modules (MKS, Chipset, VProbes)

10. USB Devices (USB module)

Some Workstation (and occasional Fusion) builds expose a USB module. vmcli --help must list USB under Available modules; otherwise every vmcli … USB … invocation fails with Invalid/unrecognized argument "USB"`.

When the module exists:

Device identifiers come from USB Query output; treat them as opaque strings.

11. Full VM clones (Clone module)

Separate from Snapshot Clone, some Workstation builds expose a top-level Clone module. Confirm with vmcli --help: many Fusion vmcli builds do not list Clone, so vmcli <vmx> Clone … fails the same way as a missing USB module.

Where Clone exists, sub-command names and flags have shifted across releases (CreateLinked, Create -t linked, and similar). Run vmcli Clone --help on the machine that will execute the job, then pin your automation to that text.

Practical Examples

Examples use VMX for the .vmx path and dirname "$VMX" for sibling files (extra disk, screenshots, logs). Use zsh or bash. On Windows, set VMX in the environment your script uses before each vmcli invocation.

!!! note "Where the .vmx path is" VM Create layout differs by product (flat folder vs *.vmwarevm bundle). Set VMX to the real .vmx after creation.

1. Create, tune, power on, optional firmware boot

vmcli VM Create -n test_vm -d ~/Desktop/ -c ubuntu-64
export VMX="$HOME/Desktop/test_vm.vmx"

vmcli "$VMX" ConfigParams SetEntry memsize 8192
vmcli "$VMX" ConfigParams SetEntry numvcpus 4
vmcli "$VMX" ConfigParams SetEntry vhv.enable TRUE
vmcli "$VMX" ConfigParams query | grep -E "memsize|numvcpus|vhv"

vmcli "$VMX" Power Start

# Optional: firmware or EFI setup on the *next* boot only (cleared after that boot)
# vmcli "$VMX" ConfigParams SetEntry bios.forceSetupOnce TRUE
# vmcli "$VMX" Power Start

2. Extra disk, JSON checks, screenshot

vmcli "$VMX" Disk Create \
  -f "$(dirname "$VMX")/test_vm-data.vmdk" \
  -a lsilogic \
  -s 50GB \
  -t 0
vmcli "$VMX" Disk query

# Same `-f json` calls as the table under "JSON output for scripting"
vmcli "$VMX" Power query -f json
vmcli "$VMX" Snapshot query -f json
vmcli "$VMX" Guest query -f json
vmcli "$VMX" Tools Query -f json
vmcli "$VMX" MKS captureScreenshot "$(dirname "$VMX")/test_vm-console.png"

3. Network (NAT to Bridged)

vmcli "$VMX" Ethernet query
vmcli "$VMX" Ethernet SetConnectionType ethernet0 bridged
vmcli "$VMX" Ethernet SetNetworkName ethernet0 "VMnet0"

4. Shared folders (HGFS)

shareLabel is the sharedFolderN slot (see the HGFS module table above).

vmcli "$VMX" HGFS SetPresent sharedFolder0 true
vmcli "$VMX" HGFS SetHostPath sharedFolder0 ~/Projects
vmcli "$VMX" HGFS SetGuestName sharedFolder0 projects
vmcli "$VMX" HGFS SetEnabled sharedFolder0 true
vmcli "$VMX" HGFS SetReadAccess sharedFolder0 true
vmcli "$VMX" HGFS SetWriteAccess sharedFolder0 true

5. VMware Tools

vmcli "$VMX" Tools Query
vmcli "$VMX" Tools Install
vmcli "$VMX" Tools Upgrade

6. Snapshots

vmcli "$VMX" Snapshot Take pre-upgrade -d "State before upgrading kernel"
vmcli "$VMX" Snapshot query
vmcli "$VMX" Power Stop -o trySoft
vmcli "$VMX" Snapshot Revert 1
# VM must be off or suspended to delete snapshots
vmcli "$VMX" Snapshot Delete 1
# When you need to drop child snapshots too, use -d before the UID (see `Snapshot Delete --help` on your build)
# vmcli "$VMX" Snapshot Delete -d 1

7. Guest Operations (Credentials)

Guest run, file copy, and ps need -u and -p (see the Guest module above). Export GUEST_PASS yourself; don't paste real passwords into shell history.

!!! warning "Credential Handling" Yes, -p on the command line is ugly. So is storing the password in a script file. For automation, use environment variables or a secrets manager and pass them at runtime instead of hard-coding them.

# Set GUEST_PASS in your environment before running these lines (never log real values).

vmcli "$VMX" Guest run -u root -p "$GUEST_PASS" \
  /bin/bash -c "apt-get update && apt-get upgrade -y"

vmcli "$VMX" Guest copyTo -u admin -p "$GUEST_PASS" \
  /path/on/host/nginx.conf /etc/nginx/nginx.conf

vmcli "$VMX" Guest copyFrom -u admin -p "$GUEST_PASS" \
  /var/log/syslog "$(dirname "$VMX")/guest-syslog.txt"

vmcli "$VMX" Guest ps -u admin -p "$GUEST_PASS"

vmcli "$VMX" Guest run -u admin -p "$GUEST_PASS" -nw \
  /usr/bin/python3 /opt/scripts/bootstrap.py

Demos

Two short screen recordings from a local Fusion Ubuntu guest (paths match a *.vmwarevm bundle on macOS). Keep "$VMCLI" quoted so VMware Fusion.app paths don't split at the space.

Snapshots, Tools, Power and Guest Query

Copy Host File to Guest, then List

Treat vmcli as a thin wrapper over desktop hypervisor operations: set VMX once per script or session, call one module at a time, and lean on --help when a flag changes between Fusion and Workstation builds.

!!! tip "Quick Reference" Run vmcli <module> --help for module-level syntax, and vmcli <vmx> <module> <sub-command> --help for a specific operation.

Requests vs. HTTPX: Choosing a Python HTTP Client

requests earned its reputation honestly. For a long time, if you needed to call an API, download a file, or glue two services together in Python, requests was usually the obvious answer.

Async web frameworks, high-concurrency services, and I/O-heavy workloads changed what many teams need from an HTTP client. That's where httpx starts to matter.

This post compares requests and httpx from the point of view of a Python developer who already knows requests, wants a clear explanation of what httpx adds, and doesn't want hand-wavy "modernization" advice.

The Champion: requests

requests became the standard because it removed friction. Small API. Sensible defaults. Session when you need reuse.

• The API is small and easy to learn.
• The defaults are simple enough for scripts and internal tools.
• Session gives you connection reuse and shared configuration without much ceremony.
• The ecosystem around it is huge: tutorials, examples, blog posts, Stack Overflow answers, and third-party integrations all assume you know requests.

For synchronous Python code, it's still a good library. A lot of production code doesn't need async support, doesn't need HTTP/2, and doesn't need a broader transport model. In those cases, requests remains a sensible choice.

That's why this comparison is not really about replacing a bad tool. It's about recognizing where the older tool stops fitting as cleanly.

The Challenger: httpx

httpx looks familiar on purpose. The synchronous API feels close enough to requests that most Python developers can read it immediately. That compatibility is one of its best features, because it lowers the cost of trying it.

Its two biggest advantages are:

• Native async and await support through httpx.AsyncClient
• Optional HTTP/2 support on both sync and async clients

Those aren't cosmetic differences.

Async support means httpx fits naturally into frameworks like FastAPI, Starlette, and any other async application that should not block the event loop on outbound network calls. HTTP/2 support means one client connection can handle multiplexed requests when the remote server supports it, which can matter for high-concurrency workloads.

You opt in with httpx.Client(http2=True) or httpx.AsyncClient(http2=True), and the server still has to support HTTP/2 for you to get it.

httpx also pushes users toward safer networking defaults. The biggest example is timeouts: requests doesn't time out unless you ask it to, while httpx enforces timeouts by default.

Decoding the Major and Minor Pentatonic Scales

If you've ever felt trapped inside the classic minor pentatonic box, you're not alone. The good news is that the box isn't the problem. The real breakthrough comes when you understand what the notes inside that shape are doing, and that's the moment the fretboard starts making sense.

Most intermediate players start in the same place: Minor Pentatonic Position 1, fingers parked at the 5th fret, trying to find fresh ideas out of the same old lick. While that scale shape is useful, but it can start to feel a bit clostrophobic.

My goal with this post is to help you:

• Stop seeing pentatonic scales as random patterns.
• Start seeing them as intervals, Root Notes, and musical colors.
• Learn why major and minor pentatonic scales are deeply connected.
• Use that connection to make better phrases anywhere on the neck of the guitar.

The word pentatonic just means five notes.

That's the whole idea:

• A major scale has 7 notes.
• A natural minor scale has 7 notes.
• A pentatonic scale trims that down to 5.

Why remove two notes?

Because the notes that are left out are the ones that create the strongest half-step tension. Whilst half-steps aren't bad, they're the notes most likely to sound tense, crunchy, or like they want immediate resolution. When you remove them, the scale becomes smoother and more forgiving.

That's why pentatonic scales are awesome:

• They're easy to hear.
• They're easy to phrase.
• They sit well over a range of chords.
• They quickly sound musical, even before your theory knowledge is deep.

On the guitar, the pentatonic scales work so well because they remove some of the strongest tension notes from the full scale. You can still create emotion and movement, but you're less likely to land on a note that feels harsh or unresolved by accident.

Hay for the Heifers

Nginx: A Practical Deep Dive

Nginx ends up in front of a surprising amount of web traffic. You might not think much about it until you have to troubleshoot a redirect loop, a broken certificate renewal, or an application that only fails once it sits behind a proxy.

Static sites, application servers, APIs, internal tools, container platforms, and CDN origins often have Nginx somewhere out front. People keep using it because it's fast, it's predictable, and it makes you declare what the server should do.

This guide walks through the part that matters in practice: what Nginx is good at, how its config model works, how to install it, how to serve a site, how to terminate TLS, how to replace .htaccess style behavior the Nginx way, and how to use it as a reverse proxy and a basic load balancer.

Nginx is a web server, reverse proxy, and load balancer. In a modern stack it usually does one or more of these jobs:

• Serves static files directly.
• Terminates HTTPS connections.
• Redirects HTTP to HTTPS.
• Proxies requests to application servers.
• Balances traffic across multiple backend services.
• Adds request and response headers.
• Buffers slow clients away from backend applications.
• Enforces simple access control rules.
• Caches upstream responses when configured to do so.

It's especially good at static assets, reverse proxying, and a lot of concurrent connections. It also works well as the boring edge layer in front of applications written in Node.js, Python, Go, Ruby, PHP, Java, or anything else that can listen on a port.

The simplest mental model:

graph TD
    A[Client Browser] -->|HTTPS Request| B[Nginx]
    B -->|HTTP Request to Local App| C[Backend Application]

Nginx does not need to understand your application. It just needs to accept the request, apply the rules you gave it, and either serve the response or pass the request upstream.

Nginx became popular because it handles several common infrastructure problems without much drama:

• It handles many concurrent connections efficiently.
• It serves static files quickly.
• It's excellent as a reverse proxy.
• It's good at shielding backend apps from awkward client behavior.
• It centralizes TLS, redirects, headers, and access control.
• It can load balance traffic without a separate appliance.
• Its configuration is explicit and reviewable.

Nginx expects configuration in known files, not hidden per-directory overrides inside the document root. That makes behavior easier to inspect, version, test, and deploy.

VMware Workstation and Fusion 26H1 Release

VMware Workstation Pro and Fusion Pro 26H1 shipped recently and was a fairly quiet release.

The biggest change in Workstation Pro 26H1 is the move to a fully 64-bit architecture on Windows. Operating systems and hardware moved on from 32-bit limitations a long time ago, but parts of Workstation's underlying components were still dragging legacy dependencies forward.

The 26H1 release finally drops them. Installers, services, libraries, and application binaries now operate entirely in a 64-bit environment. It's a cleanup that eliminates years of technical debt and gets out of the way of heavy edge-case workloads on the Windows side.

In 26H1, you can finally see when a virtual machine was created and when it was last powered on.

If you manage a handful of virtual machines, you probably won't care. If you manage dozens, or maintain a sprawling cybersecurity lab, this is a massive quality-of-life fix. It's significantly easier to find dormant lab machines without having to boot them or guess based on filesystem modification dates.

The most impactful part of 26H1 isn't technical. Since Workstation Pro and Fusion Pro are now free for personal, educational, and commercial use, the economics of local virtualization are completely different. You don't have to justify a license request or fall back to an open-source alternative with fewer features. You can just download the premier desktop hypervisor and run your lab.

The 26H1 release includes a typical collection of bug fixes and security updates to improve platform stability. When you rely on virtual machines as part of your daily workflow, predictable execution matters more than new knobs to turn.

How I'm Preparing for GH-600, GitHub's Agentic AI Developer Certification

When I published Branching Out: GitHub Certification Path, GitHub had five certifications. That list is already out of date, and so is my own exam roadmap.

GitHub has now added a sixth exam: GH-600, GitHub Certified: Agentic AI Developer (beta). As of June 6, 2026, this one is still in beta, and it fills a different role than the existing Copilot certification. The Copilot exam is about using GitHub's AI tooling well. GH-600 is about building, operating, constraining, and evaluating agents inside real software delivery workflows.

I'm treating this post as my preparation plan for GH-600. These are the official materials, docs, and hands-on exercises I'm using to get ready for it.

GitHub is treating agentic AI as an engineering discipline: tool access, MCP configuration, execution boundaries, memory, observability, evaluation, and guardrails. That's the right frame for the technology, and it's the reason this exam is worth taking seriously.

Versioning Documentation with ProperDocs and mike

If you're using ProperDocs, versioned publishing should be straightforward. Build the docs for a release, publish them under a stable version label, and leave older versions alone. Until mike v2.2.0, that simple workflow still carried a nagging question: did the rest of the tooling really understand ProperDocs, or was it still assuming MkDocs under the hood?

mike publishes each supported release as its own directory tree on a deployment branch, usually gh-pages. Old versions stay put even when today's main branch moves on. In the mike v2.2.0 release, that process got simpler for ProperDocs users: when the properdocs package is installed, mike runs properdocs instead of mkdocs. No separate workflow branch. No wrapper script. No extra switch to remember.

The release notes include:

Add support for ProperDocs.

In practice, that means mike now checks for the properdocs package first. When it's present, mike uses the properdocs command and includes properdocs.yml and properdocs.yaml in its default configuration file search order.

That is exactly the kind of compatibility work you want in a documentation pipeline. Install the generator you actually use, install mike, and let tool detection do the boring part correctly.

ProperDocs exists because some teams need the MkDocs 1.x operating model to keep working. They have plugins, theme overrides, snippets, macros, and workflow assumptions built around that ecosystem. Versioned publishing shouldn't force those teams into a second set of build logic.

Before this change, the friction wasn't that versioned docs were impossible. The friction was that ProperDocs users had to think too much about whether the surrounding tooling still assumed MkDocs. That extra uncertainty is how CI jobs grow unnecessary conditionals and side paths.

With mike v2.2.0, the command flow is really simple:

python -m pip install "properdocs" "mike>=2.2.0"
mike deploy 1.0 latest --push

PowerShell Command Naming: Approved Verbs, Clear Nouns, and Better APIs

The difference between a PowerShell command that feels native and one that feels bolted on is often not the implementation. It's the name. In PowerShell, names are part of the interface contract: they drive discoverability, shape user expectations, and determine whether your module behaves like a first-class citizen or like a private script someone published by accident.

If you maintain PowerShell modules long enough, you start to see the same mistakes over and over:

• Functions named with verbs PowerShell doesn't recognize
• Plural nouns where PowerShell expects singular object names
• Verb choices that imply one behavior while the function performs another
• "Do everything" verbs like Invoke used as a substitute for design
• State-changing commands that don't support -WhatIf and -Confirm

This post is about avoiding those mistakes and building command names that feel idiomatic, predictable, and maintainable.

A bad command name spreads farther than you might expect. It shows up in documentation, examples, tab completion, issue reports, code review comments, CI logs, and muscle memory. Once users learn the wrong name, you either carry it forward forever or you break them later when you fix it.

PowerShell isn't just a shell. It's a command discovery environment. Users don't need to remember your entire module if your names fit the ecosystem. They can find commands through patterns:

Get-Command -Verb Get
Get-Command -Module My.Module
Get-Command -Noun VcfCluster
Get-Help Get-VcfCluster -Full
Get-Verb

That only works well when command names follow the conventions the engine, the help system, and the user all expect.

The best PowerShell command names are easy to guess. If I know your module has a cluster object, I should be able to guess that retrieval is probably Get-Thing, creation is probably New-Thing, mutation is probably Set-Thing, deletion is probably Remove-Thing, and validation is probably Test-Thing. If your module breaks that expectation, you increase the amount of documentation the user must read before they can do anything useful.

Seminole Clay