vCenter Resize API and Image Integrity in vSphere 9.1 Two Runbook Upgrades Hiding in the Release Notes

A single PATCH call to resize vCenter, and SHA256 checksums on vLCM image definitions. Small features that move vCenter administration toward declarative, verifiable, API-driven operations.

Share

Some release notes change keynotes; others change runbooks. vSphere 9.1 ships two of the latter: an API-driven vCenter resize and SHA256 integrity checksums on vSphere Lifecycle Manager images. Neither will appear on a customer slide. Both belong in your operational documentation.

vCenter Resize via API

vSphere 9.1 introduces a deployment/size API that makes resizing vCenter a single API call plus a reboot. The API uses the PATCH method and can be initiated from the Developer Center API Explorer inside vCenter. Compute and disk sizes scale up through one operation.

Why it matters: resizing vCenter was previously a manual, multi-step exercise that estates deferred until resource pressure became a problem. As an API operation, it becomes scriptable which means it can live inside capacity management automation. When VCF Operations capacity insights flag vCenter resource pressure, remediation is one call in a workflow, not a change request that waits three weeks for a window. The reboot still needs scheduling, but with vCenter Reduced Downtime patterns in 9.1, the tolerance for brief vCenter events is already built into the operating model.

Image Integrity via SHA256

Images created and managed by vSphere Lifecycle Manager now include a SHA256 checksum of the image definition. Export an image from one vCenter, import it into another, compare checksums at source and destination integrity of the definition confirmed. Broadcom is precise about scope: this is a checksum of the image definition, not of the ESX VIBs themselves.

The estates that feel this immediately are the ones that promote validated images through environments dev to staging to production or distribute a golden image across sites. The compliance question “how do you know production runs the image you validated?” previously had a procedural answer. Now it has a cryptographic one. For FSI change-management evidence, that’s a material upgrade: attach the checksum comparison to the change record and the question is closed.

The Pattern Worth Noticing

Both features push the same direction: vCenter administration becomes declarative, verifiable, and API-driven. Resize is an API call; image integrity is cryptographically checkable; patching (Quick Patch) is automated; upgrades (Reduced Downtime) are migration-based and recoverable. The management plane is steadily converging on the operational properties we’ve demanded of workloads for years. Design your runbooks to exploit that script the resize, checksum the promotions, and retire the manual procedures those runbooks used to describe.

The Architect’s Takeaway

Add two lines to the LLD: vCenter sizing changes are executed via the deployment/size API under capacity-management automation, and image promotion between vCenter instances requires SHA256 checksum verification at source and destination. Neither line costs anything to write. Both remove a class of manual error that surfaces at the worst possible time.

Sources

Broadcom What’s New with vSphere in VMware Cloud Foundation 9.1

Broadcom Modernizing the Private Cloud: Why VCF 9.1 Lifecycle Management is a Game Changer

Broadcom Scale, Simplify, and Secure Your Private Cloud Operations with VCF 9.1