Eric Sloof

VMware vSAN stands as a cornerstone of the modern Software-Defined Data Center (SDDC), offering robust, high-performance, and scalable storage solutions integrated directly into the hypervisor. As the technology evolves, keeping up with the latest advancements is crucial for architects, administrators, and IT professionals. This article distills the essential takeaways from the comprehensive VMware vSAN FAQ document, providing a clear overview of its core concepts, latest features, and deployment architectures. For a more interactive deep dive, be sure to check out my upcoming video walkthrough on this topic, created with NotebookLM.

Core Architectural Pillars: OSA vs. ESA

vSAN offers two distinct architectures: the Original Storage Architecture (OSA) and the newer, high-performance Express Storage Architecture (ESA). Understanding their differences is key to designing and deploying a modern vSAN cluster.

While the OSA remains a viable option for existing hardware, all new deployments should be designed for the ESA to leverage its superior performance, efficiency, and lower Total Cost of Ownership (TCO) .

Flexible Deployment Models

vSAN is not a one-size-fits-all solution. It provides several deployment models to cater to different infrastructure needs, from the data center core to the edge.

•vSAN HCI (Hyperconverged Infrastructure): This is the traditional, aggregated model where compute and storage resources reside within the same cluster. It simplifies management and is ideal for a wide range of workloads.

•vSAN Storage Clusters: Previously known as vSAN Max, this disaggregated model separates compute and storage into independent clusters. It allows you to scale storage and compute resources independently, providing a centralized, highly scalable storage platform for multiple vSphere clusters. This is particularly beneficial for optimizing licensing costs and managing large-scale environments .

•Stretched and 2-Node Clusters: These topologies provide high availability and site-level resilience. Stretched clusters span two geographic locations, while 2-Node clusters are designed for Remote Office/Branch Office (ROBO) and edge environments, using a third-site witness to maintain data quorum.

Key vSAN Capabilities

Beyond its architecture, vSAN is packed with features that ensure data availability, security, and operational simplicity.

Availability: vSAN protects against failures at multiple levels, including individual disks, entire hosts, and even network partitions. By setting Storage Policy-Based Management (SPBM) rules like "Failures to Tolerate" (FTT), administrators can define the desired level of data redundancy for each virtual machine.

Security: vSAN provides both Data-at-Rest and Data-in-Transit encryption using the AES-256 cipher. This can be managed through external Key Management Service (KMS) solutions or the vSphere Native Key Provider (NKP), without requiring specialized self-encrypting drives (SEDs) .

Performance and Operations: Tools like HCIBench allow for standardized performance testing, while features like adaptive resynchronization minimize the performance impact of maintenance operations. The Skyline Health service in vCenter provides comprehensive monitoring and proactive diagnostics to ensure your cluster runs optimally.

Explore Further

The world of vSAN is deep and constantly evolving. This article provides a high-level overview of the key concepts you need to know. To get the full details and answers to more specific questions, I highly recommend exploring the official documentation.

As you continue your learning journey, be sure to watch my upcoming video where I walk through these concepts in more detail using NotebookLM.

References

[1] VMware. (2025, December 12). vSAN Frequently Asked Questions.

#vExpert Eric Sloof takes us through the a new era for elite private cloud professionals with the VMware Certified Distinguished Expert (VCDX) offerings: the very best certification that marks you as a "Distinguished Private Cloud" Expert.

With the release of VMware Cloud Foundation 9.0, Broadcom has taken a significant step forward in simplifying log management and troubleshooting for private cloud environments. VCF Operations for Logs 9.0 introduces a deeply integrated logging solution that brings log analytics directly into the VCF Operations interface — making life easier for NOC teams, SREs, IT administrators, and application teams alike.

In this blog post, I'll walk you through the key new features, architecture improvements, and what this means for your day-to-day operations.

What's New in VCF Operations for Logs 9.0?

Integrated Log Analysis in VCF Operations

The biggest change in version 9.0 is the introduction of Operations-Logs, a new logging solution built on VMware Aria Operations for Logs. This means you no longer need to switch between separate interfaces to analyze your logs. Everything is now available directly within the VCF Operations UI.

With this integration, you can:

• Create log-based alerts without leaving VCF Operations
• Design custom dashboards based on log data
• Save and reuse log queries across your team
• Package alerts, dashboards, and queries into management packs

Important note: VMware Aria Operations for Logs content packs are still supported in 9.0, but Broadcom recommends starting the migration to log-based tools in management packs, as content packs will be phased out in future updates.

Deployment Options

How you deploy VCF Operations for Logs depends on your license type:

• VMware Cloud Foundation license: Activate Operations-Logs via VCF Management in VCF Operations Fleet Management — no separate appliance deployment required.
• VMware vSphere Foundation (VVF) license: Deploy the VCF Operations for Logs virtual appliance using vSphere.

Key Features

High-Performance Log Ingestion

VCF Operations for Logs is built to handle large volumes of log data at high throughput with low latency. It accepts data through two main channels:

• Syslog: ports 514/UDP, 514/TCP, and 1514/TCP (SSL)
• Ingestion API: ports 9000/TCP and 9543/TCP (SSL)

Any environment component — operating systems, applications, VMs, hosts, vCenter, firewalls, switches, and storage — can push syslog feeds to VCF Operations for Logs.

Scalable Architecture

VCF Operations for Logs supports both single-node and multi-node cluster deployments:

• Single node: Good for development and lab environments. Use the Integrated Load Balancer (ILB) even for single nodes to simplify future expansion.
• Cluster: Required for production environments. Clusters provide primary and worker nodes, enabling linear scaling of ingestion throughput and high availability.
• Cluster with Forwarders: Extend your deployment with forwarder clusters at remote sites, forwarding all logs to the main cluster. Ideal for multi-datacenter environments.
• Cross-Forwarding for Redundancy: Mirror two main clusters across datacenters, each front-ended with dedicated forwarder clusters for full redundancy.

Near Real-Time Search

Log data ingested by VCF Operations for Logs is available for search within seconds. Historical data can be queried from the same interface with equally low latency — no need to wait or switch tools.

Runtime Field Extraction

Raw log data is often difficult to parse visually. VCF Operations for Logs provides runtime field extraction, allowing you to dynamically extract any field from log data using regular expressions. These extracted fields can then be used for:

• Searching and filtering log events
• Aggregating events in the Explore Logs chart
• Building dashboard widgets

A handy one-click extract feature makes this even easier — no need to manually type complex regex patterns.

Explore Logs

The Explore Logs page is your primary workspace for log analysis. From here you can:

• Search and filter log events by timestamp, text, source, or field values
• Create and save custom queries
• Visualize query results as charts
• Pin charts to custom dashboards

Dashboards

Dashboards give you a real-time view of the metrics that matter most. You can:

• Create custom dashboards with widgets based on your own queries
• Use content pack dashboards for out-of-the-box visibility into VMware components
• Clone content pack dashboards and customize them for your needs
• Share dashboards with your team via shared dashboard URLs

Log Management

The Log Management section provides full control over how logs are handled:

• Log filtering: Reduce noise by filtering out irrelevant log data
• Log masking: Mask sensitive data before indexing
• Log forwarding: Forward logs to external destinations or other VCF Operations for Logs instances
• Index partitions: Control log retention and archiving policies

Integrations

VCF Operations for Logs integrates natively with key VMware and third-party products, including:

• vSphere (vCenter log collection via centralized configuration)
• NSX
• Identity Firewall
• Third-party syslog sources (rsyslog, syslog-ng, log4j)

The Life Cycle of a Log Event

Understanding how VCF Operations for Logs processes events helps you use the tool more effectively. Here's what happens from the moment a log event is generated:

1. Generated on a device outside VCF Operations for Logs
2. Collected via a VCF Operations for Logs agent, third-party agent, or direct API/syslog write
3. Received by VCF Operations for Logs — directed to the appropriate node via the ILB
4. Processed through the ingestion pipeline:
   • Keyword index created and stored on local disk
   • Machine learning applied to cluster events
   • Event stored in compressed format
5. Available for search within seconds
6. Archived or deleted based on retention policies (FIFO deletion when storage reaches 97% capacity)

What This Means for Your Teams

Getting Started

To start using VCF Operations for Logs 9.0:

1. If you have a VCF license, activate Operations-Logs via Fleet Management → VCF Management
2. Configure your environment components to forward syslog to VCF Operations for Logs
3. Explore the Explore Logs page and start building your first queries
4. Create dashboards to monitor your most important metrics
5. Set up log-based alerts to get notified proactively

Conclusion

VCF Operations for Logs 9.0 represents a major step forward in how VMware Cloud Foundation environments handle log management and troubleshooting. By integrating log analytics directly into VCF Operations, Broadcom has made it significantly easier for teams of all types to gain visibility into their infrastructure and applications — without additional tools or context switching.

Whether you're troubleshooting a failed deployment, investigating a performance issue, or simply keeping an eye on your environment's health, VCF Operations for Logs 9.0 has the tools you need.

Some milestones make you stop and think. receiving the VMware vExpert 2026 award — for the eighteenth consecutive year — is one of them.

Eighteen years. That's a long time in any industry, but in the world of enterprise virtualization and cloud infrastructure, eighteen years feels like several lifetimes. When I received my first vExpert recognition, VMware ESX was still a thing, vSphere was just emerging, and the idea of software-defined networking was barely on the horizon. Today, the conversation is about VMware Cloud Foundation, NSX, automation pipelines, and multi-cloud architectures. The technology has changed enormously. The community spirit, fortunately, has not.

What the vExpert Program Actually Means

The vExpert award isn't a certification. It's not something you study for or pass an exam to earn. It's a recognition by VMware — now part of Broadcom — of ongoing, real-world contributions to the broader VMware community. That can take many forms: blogging, presenting at VMUG events, creating training content, helping peers troubleshoot complex issues, or simply being a consistent and reliable voice in the community.

For me, it has always been about sharing what I learn in the field. Enterprise environments are messy, complex, and full of edge cases that no documentation ever quite covers. Over the years, the things I've written about, the sessions I've delivered, and the conversations I've had with fellow engineers have all come from that same place: "I just solved something hard, and someone else will run into this too."

That spirit of practical knowledge sharing is exactly what the vExpert program recognizes, and it's why being part of this community still feels meaningful after nearly two decades.

Looking Back — and Forward

Reflecting on eighteen years in the vExpert program means reflecting on eighteen years of the industry itself. I've watched VMware grow from a virtualization powerhouse into a full-stack enterprise platform vendor. I've seen NSX go from a niche SDN product to the backbone of zero-trust network segmentation in major enterprises. I've lived through the shift from manual deployments to infrastructure-as-code, from on-premises-only thinking to hybrid and multi-cloud reality.

Through all of it, the core of my work has remained consistent: helping organizations make sense of complex VMware environments, whether that means designing a VCF deployment, troubleshooting an elusive NSX routing issue, or building automation that makes life easier for platform teams.

What has changed is the pace. The ecosystem moves faster now. Broadcom's acquisition of VMware brought significant changes to licensing, product bundling, and the roadmap — changes that many customers are still navigating. That makes community knowledge sharing even more important than it used to be. When the vendor documentation lags behind reality, the community fills the gap.

What's Coming in 2026

My focus for the year ahead will be squarely on VMware Cloud Foundation and NSX, with a strong emphasis on automation and practical troubleshooting. VCF has become the strategic platform for many of the organizations I work with, and there's enormous demand for content that goes beyond the marketing layer — content that addresses real deployment challenges, upgrade paths, integration considerations, and day-two operations.

I'll also continue contributing to training. One of the most rewarding parts of this work is seeing someone go from confused to confident on a technology they've been struggling with. If a blog post, video, or training session makes that happen for even a handful of engineers, it's time well spent.

Thank You

To the vExpert program team — Corey Romero and the rest of the community and advocacy team — thank you for continuing to run a program that genuinely values practitioners. And to everyone in the VMware community who reads, comments, shares, or simply nods along because you've been in the same situation: this is for you.

Here's to year eighteen, and to whatever challenges year nineteen will bring.

Broadcom recently published an updated technical paper on VMware vSAN Stretched Clusters, written by Pete Koehler (December 2025). This comprehensive guide covers everything you need to know about designing, deploying, and operating stretched clusters across two geographically separated sites using VMware Cloud Foundation (VCF) 9.0 with vSAN 9.

In this article, I summarize the key concepts, architecture decisions, and best practices from the whitepaper, and share my own thoughts on what matters most when planning a vSAN stretched cluster deployment.

You can download the full whitepaper from Broadcom here.

What Is a vSAN Stretched Cluster?

A vSAN stretched cluster extends a single vSAN cluster across two physical sites (referred to as the preferred and secondary fault domains), with a lightweight witness appliance running at a third location. This architecture provides site-level disaster recovery with near-zero RPO and automated failover using native vSphere HA — without requiring third-party replication software.

The key benefit is that data is synchronously mirrored between the two sites, meaning that if one site goes down completely, the surviving site has a full copy of all data and workloads can be restarted automatically.

Supported Architectures: OSA and ESA

vSAN stretched clusters are supported on both the Original Storage Architecture (OSA) and the Express Storage Architecture (ESA). However, there are important differences.

With ESA, the storage architecture is more efficient by design. ESA uses a single-tier storage pool (NVMe only), which simplifies disk group management and eliminates the caching tier complexity found in OSA. For stretched clusters specifically, ESA supports adaptive erasure coding within each site — meaning you can use RAID-5 or RAID-6 locally at each site while still mirroring data across sites. This combination provides excellent space efficiency without sacrificing resilience.

OSA stretched clusters still work well, but ESA is the recommended path forward for new deployments.

The Witness Appliance

The witness appliance is a critical component of any vSAN stretched cluster. It does not store actual VM data — instead, it holds witness components that act as a tiebreaker during network partitions or site failures. The witness must be deployed at a third location, separate from both data sites.

Key points about the witness:

• It runs as a small virtual appliance (tiny, medium, or large, depending on the number of components)
• It requires network connectivity to both data sites, but latency requirements are more relaxed (up to 200ms RTT to each site)
• It should never run inside the stretched cluster itself
• Multiple stretched clusters can share a single witness host, but each cluster needs its own witness appliance
• The witness does not need high bandwidth — 100 Mbps is sufficient for most deployments

A common mistake is placing the witness at one of the data sites. This defeats the purpose of having a third fault domain and creates a single point of failure during site isolation events.

Network Requirements

Networking is arguably the most critical design consideration for vSAN stretched clusters. The two data sites must have low-latency, high-bandwidth connectivity between them.

The requirements are straightforward but non-negotiable. Between the two data sites, you need a maximum of 5ms RTT latency for vSAN traffic. A minimum of 10 Gbps bandwidth for vSAN traffic is required, though 25 Gbps is recommended. Between each data site and the witness, up to 200ms RTT latency is acceptable, and 100 Mbps bandwidth is sufficient.

vSAN traffic between sites should be on a dedicated or isolated network segment, and it is highly recommended to use jumbo frames (MTU 9000) for optimal performance. For ESA deployments with RDMA, both sites need to support RoCE v2 within each site (RDMA is not used across sites).

Fault Domains and Site Affinity

In a vSAN stretched cluster, you define two fault domains — one for each data site. Every ESXi host is assigned to either the preferred or secondary fault domain. The witness appliance operates as its own implicit fault domain.

When a VM is created, vSAN places one full copy of data at the preferred site and one full copy at the secondary site, plus a witness component on the witness appliance. This ensures that any single site failure still leaves a quorum of components available.

Site affinity is an important concept for workloads that should preferably run at a specific site. You can use VM-Host affinity rules in DRS to keep VMs at their designated site during normal operations, while still allowing failover to the other site during a disaster.

vSphere HA and DRS Configuration

Getting the HA and DRS settings right is essential for proper stretched cluster behavior.

For vSphere HA, the recommendation is to set the admission control policy to 50% for both CPU and memory. This reserves enough capacity at each site to absorb the full workload from the other site during a failure. Host monitoring should use vSAN network heartbeating, and the isolation response should be set to "Power off and restart VMs."

For DRS, the automation level should be set to "Fully Automated." Use VM-Host affinity rules (should rules, not must rules) to prefer VMs at their designated site. This allows DRS to override placement during a failover event. During normal operations, DRS will respect the affinity rules and keep VMs at their preferred site.

Storage Policies for Stretched Clusters

vSAN stretched clusters use a specific storage policy setting: the site disaster tolerance policy. This is set separately from the standard FTT (failures to tolerate) setting.

The site disaster tolerance defines how data is mirrored across sites. The most common configuration is "Site mirroring" (also called dual site mirroring), which creates one full copy at each data site.

Within each site, you can additionally configure local FTT protection. For example, on ESA you can set FTT=1 with RAID-5 at each site, combined with site mirroring across sites. This means data is protected against both a full site failure and an additional host failure at the surviving site.

This layered protection model is one of the major advantages of vSAN stretched clusters — you get both local resilience and site-level disaster recovery in a single, unified storage policy.

Maintenance and Day-2 Operations

Operating a stretched cluster requires understanding the impact of maintenance activities at each site.

When placing a host in maintenance mode, you should choose "Ensure accessibility" for routine maintenance tasks. This avoids unnecessary data migrations between sites. For permanent host removal, use "Full data migration" to evacuate all components.

During a planned site maintenance event (such as power maintenance at one data center), you can use the "Decommission Fault Domain" workflow. This gracefully migrates all VMs to the other site and ensures data integrity before the site goes offline.

Lifecycle management through VCF SDDC Manager handles firmware and software upgrades in a rolling fashion, maintaining availability throughout the update process.

Failure Scenarios and Recovery

The whitepaper covers multiple failure scenarios in detail. Here are the most important ones.

In a single host failure, VMs are restarted on remaining hosts at the same site. vSAN rebuilds missing components using hosts at the same site if possible.

In a full site failure, vSphere HA restarts all affected VMs at the surviving site. Because a full data copy exists at the surviving site, VMs can restart immediately without waiting for data rebuilds.

In a network partition between sites, the preferred site retains quorum (because it has data + witness), and VMs at the secondary site are powered off and restarted at the preferred site. This is why the "preferred" designation matters.

In a witness isolation, both data sites continue operating normally. No VM impact occurs. The witness is only needed during site-level events.

My Recommendations

Based on my experience with vSAN stretched clusters, here are a few practical recommendations.

First, invest in network quality. The number one cause of stretched cluster issues is network problems between sites. Ensure you have redundant, low-latency links with proper QoS for vSAN traffic.

Second, use ESA if you are deploying new infrastructure. The performance and efficiency benefits of ESA are significant, especially the ability to use erasure coding within each site.

Third, test your failure scenarios. Before going into production, simulate site failures, network partitions, and witness outages. Verify that HA and DRS behave as expected.

Fourth, document your affinity rules. Keep a clear mapping of which VMs belong to which site, and review this regularly as workloads change.

Finally, size your witness appropriately. For large environments with many VMs, use the large witness appliance to handle the additional component count.

Conclusion

vSAN stretched clusters remain one of the most elegant solutions for site-level disaster recovery in a VMware environment. With VCF 9.0 and vSAN 9, the technology has matured significantly — particularly with ESA bringing better performance and simpler operations.

The official Broadcom whitepaper is an excellent resource for anyone planning or operating a stretched cluster. I highly recommend reading it in full.

Download the whitepaper