Browsing: Guides & Tutorials

VMware vSphere Foundation and VMware Cloud Foundation share the same infrastructure DNA. Both are built around vSphere. Both can run enterprise virtual machines. Both include vSAN capacity, VMware vSphere Kubernetes Service, and VCF Operations capabilities. That shared foundation makes the comparison easy to get wrong. VVF 9.0 is not simply a smaller release of VCF, and VCF 9.1 is not just vSphere with more features switched on. They represent different operating models. VVF 9.0 is primarily a workload and hyperconverged infrastructure platform. It gives infrastructure teams a strong compute, storage, Kubernetes, and operations foundation while preserving a familiar vCenter-led administration…

TL;DR VCF 9.1 supports two distinct approaches for connecting Virtual Private Clouds to the physical data center network. A Distributed Transit Gateway removes NSX Edge nodes, the Tier-0 gateway, and BGP from the north-south forwarding path. Traffic can leave directly from the ESXi host through a VLAN shared by every participating host. The design reduces architecture overhead and can eliminate an Edge forwarding hop, but it depends heavily on consistent Layer 2 reachability, physical gateway behavior, host uplink configuration, IP address management, and workload mobility convergence. A Centralized Transit Gateway sends external traffic through NSX Edge nodes and a Tier-0…

Most private AI conversations start too low in the stack. The first question is usually some version of, “Can we run the model on-prem?” That is not a bad question, but it is not the architecture question. Running a model on-premises proves that you can place compute near data. It does not prove that you have a private AI platform. That is the difference between model hosting and private AI. Model hosting is a deployment task. Private AI is an operating model. That distinction matters because Broadcom is positioning VMware Cloud Foundation 9.1 as a production AI private cloud platform,…

TL;DR An AI agent is not production-ready because it can complete a demonstration. It is production-ready when the organization can prove who is acting, what state is retained, which tools are permitted, how behavior is evaluated, what telemetry is captured, where approvals interrupt execution, how cost is bounded, how failures are contained, and who owns the service. The practical shift is from a prompt-and-model prototype to a governed execution system. Treat identity, state, tools, policy, observability, evaluation, recovery, and ownership as separate control planes. Put measurable release gates around each one. Start with a narrow workflow, run it in shadow…

Moving from VCF 9.0 to VCF 9.0.1 looks small on paper. It is not a platform redesign, not a brownfield conversion, and not the same class of change as a major-version upgrade. That is exactly why it deserves discipline. Maintenance upgrades are where teams are tempted to move too quickly. The release appears incremental, the target version is close, and the change window feels predictable. But VCF is still a composed platform. Fleet-level components, SDDC Manager, NSX, vCenter, ESX hosts, vSAN services, identity, logs, automation, and observability all participate in the operating model. Even when the release is limited in…

TL;DR MCP and A2A solve different integration problems. Use Model Context Protocol when an AI application needs a standard way to discover and use tools, resources, prompts, APIs, or enterprise data. Use Agent2Agent when one independently operated agent needs to discover another agent, delegate work, exchange messages, track a task, receive progress updates, and consume returned artifacts. The practical distinction is more precise than “models use MCP and agents use A2A.” MCP standardizes the capability boundary between an AI host and an MCP server. A2A standardizes the collaboration boundary between independently operated agentic applications. Many production architectures need both. A…

TL;DR Local AI in 2026 is no longer limited to a command-line chatbot. A practical local stack can include model runtimes, desktop assistants, private document search, coding agents, visual orchestration, image workflows, transcription, and offline translation. The best starting point depends on the layer you need. Ollama, llama.cpp, KoboldCpp, LocalAI, and TextGen focus on model execution. LM Studio, Jan, GPT4All, and Msty Studio provide more approachable desktop experiences. Open WebUI and AnythingLLM add browser access, retrieval, and knowledge workflows. Open Interpreter, Cline, Aider, and Flowise extend local models into action and automation. ComfyUI, InvokeAI, whisper.cpp, and Argos Translate cover creative…

TL;DR The essential AI agent repository list in 2026 is no longer just a collection of frameworks and tutorials. A credible engineering stack now includes protocol specifications, official SDKs, server discovery, agent-to-agent interoperability, durable orchestration, evaluation, OpenTelemetry-compatible tracing, red teaming, and operational security guidance. This refresh identifies 20 repositories that help architects and engineers build the complete system. The list is grouped by role rather than ranked by popularity: MCP foundations, A2A interoperability, agent frameworks, evaluation and observability, and agent security. It was validated on July 20, 2026. That date matters because the MCP Python and TypeScript v2 lines were…

TL;DR An HCX 9.1 migration should not begin with the Migrate Virtual Machines button. It should begin with a dependency-ordered runbook that proves routing, firewall policy, IP pools, site pairing, Network Profiles, Compute Profiles, Service Mesh health, and Network Extension behavior before a production workload is touched. The practical sequence is: Confirm supported versions, backups, DNS, NTP, certificates, routes, and firewall ownership. Reserve unique, non-overlapping HCX appliance IP pools at both sites. Establish and validate HCX site pairing over TCP 443. Create Network Profiles for the required traffic types. Create Compute Profiles that constrain placement and enable only the required…

TL;DR PowerCLI is now distributed through the VCF.PowerCLI package. The older VMware.PowerCLI package is deprecated, although many familiar cmdlets and underlying VMware.* modules remain in use. For a new installation, use: Install-Module -Name VCF.PowerCLI ` -Scope CurrentUser ` -Repository PSGallery For an existing VMware.PowerCLI installation, audit scripts for explicit Import-Module VMware.PowerCLI statements, prefer a clean migration where practical, and use -AllowClobber and -SkipPublisherCheck only when resolving the documented upgrade conflicts. VCF PowerCLI 9.1 can also be installed offline by downloading the complete Broadcom ZIP package or staging the package and its dependencies with Save-Module. Offline installations cannot be updated with…