5.1 Block Storage Architecture, Fibre Channel & VMFS Datastores

5.1 Block Storage Architecture, Fibre Channel & VMFS Datastores

Enterprise virtualization depends fundamentally on robust, low-latency, resilient shared storage. VMware vSphere Foundation (VVF) supports diverse storage architectures, ranging from traditional block storage area networks (SAN) to file-based network-attached storage (NAS) and modern hyperconverged architectures like VMware vSAN. Understanding how the ESXi VMkernel discovers, encapsulates, locks, and formats raw block storage devices into shared clustered file systems is central to Objective 2.3 of the certification blueprint.

---

Enterprise Block Storage Protocols & SAN Fabric Architecture

In block storage architectures, a storage array carves raw physical drive capacity into logical storage volumes known as Logical Unit Numbers (LUNs). These LUNs are presented across a storage network (fabric) to ESXi hosts, where the VMkernel mounts them as raw SCSI or NVMe targets and formats them with the Virtual Machine File System (VMFS).

1. Fibre Channel (FC) Architecture & Addressing

Fibre Channel is a high-speed, lossless serial data transfer architecture engineered specifically for storage area networks. ESXi hosts connect to FC storage switches via dedicated Host Bus Adapters (HBAs). Fibre Channel devices are identified by two distinct 64-bit hexadecimal addresses:

• World Wide Node Name (WWNN): Identifies the overall physical device or storage array controller chassis. A dual-port HBA card has a single WWNN representing the physical adapter.
• World Wide Port Name (WWPN): Identifies an individual physical port on the HBA or storage controller. A dual-port HBA card features two unique WWPNs (one per optical transceiver port). For zoning and LUN masking, WWPNs are the primary operational identifier (formatted as 20:00:00:25:B5:11:22:33).

2. Fibre Channel Access Control

Zoning controls initiator-to-target fabric communication; LUN masking controls which storage volumes an initiator can access. They solve different problems. WWPN-based zone membership can remain stable when a cable moves, but membership by name is not the same as a claim about how the switch enforces zoning in hardware.

Use the SAN vendor's supported zoning pattern, commonly a single initiator with approved targets. Validate both fabrics independently, record host and target identities, and confirm the LUN mapping before rescanning. Never format a device merely because it appears in a rescan: verify its unique ID, capacity and whether another datastore already uses it.

4. Modern NVMe over Fabrics (NVMe-oF)

Legacy block storage relies on the SCSI architecture, which was designed in the era of spinning magnetic platters and features a single, centralized command queue with limited queue depths (typically 32 to 256 commands). Modern Non-Volatile Memory Express (NVMe) solid-state drives bypass SCSI controllers entirely, communicating directly across PCIe lanes with up to 64,000 parallel queues, each supporting 64,000 commands.

NVMe over Fabrics (NVMe-oF) extends the low-latency, highly parallel NVMe command protocol across network fabrics to external storage arrays:

• NVMe over Fibre Channel (NVMe/FC): Runs NVMe protocol encapsulation directly over existing 16G/32G/64G Fibre Channel infrastructure using standard FC HBAs and switches. It coexists transparently with traditional FCP (SCSI) traffic on the same physical fabric.
• NVMe over TCP (NVMe/TCP): Transports NVMe command sets across standard, off-the-shelf TCP/IP Ethernet networks without requiring specialized RDMA-capable NICs or proprietary switching. This dramatically lowers the cost of deploying ultra-low-latency NVMe shared storage in enterprise datacenters.
• NVMe Addressing: Instead of WWPNs or SCSI LUN IDs, NVMe-oF identifies endpoints using NVMe Qualified Names (NQNs), such as nqn.2014-08.com.vmware:nvme:esxi01. Storage volumes are presented as Namespaces rather than SCSI LUNs.

---

Comparison of Enterprise Block Storage Protocols

---

VMFS Clustered File System Architecture (VMFS-6)

When a raw block LUN or NVMe namespace is mapped to ESXi hosts, it must be formatted with the Virtual Machine File System (VMFS) to store virtual machine files (.vmdk, .vmx, .nvram, .vswp).

VMFS is a high-performance, multi-host clustered file system. Unlike traditional operating system file systems (such as NTFS or ext4), which assume exclusive access to a block device and will corrupt metadata if mounted simultaneously by two servers, VMFS allows multiple supported ESX hosts to mount the exact same datastore concurrently with simultaneous read and write access.

Clustered Locking and Space Reclamation

VMFS coordinates access from multiple ESX hosts, preventing competing writers from corrupting a VM's files. Supported array acceleration can offload operations such as metadata locking, block copy or zeroing. Verify the supported primitives and array configuration rather than assuming every device offers identical behavior.

VMFS-6 supports automatic asynchronous space reclamation when the backing storage supports it. Deleting a VM releases filesystem space, but array capacity may be returned later through UNMAP. Guest filesystem deletion, virtual-disk allocation, VMFS free space and array-pool consumption are separate layers. Check the appropriate layer when an administrator says that deleted data has not freed capacity.

Do not promise that background reclamation has zero I/O cost or use one rate for all releases. Schedule major reclamation activity with storage monitoring. For recovery and availability, ensure every intended host sees the correct shared device and supported path configuration before placing workloads on it.

Virtual Disk Provisioning Formats & Growth Mechanics

When administrators create virtual disks (.vmdk), vSphere provides three distinct provisioning formats, each balancing storage capacity efficiency against upfront write performance:

1. Thick Provision Lazy Zeroed

• Allocation: All physical disk capacity is allocated immediately on the VMFS datastore at the time of creation. If an administrator creates a 100 GB virtual disk, 100 GB of datastore capacity is immediately consumed and cannot be utilized by other VMs.
• Zeroing Behavior: The physical blocks are not cleared of preexisting data on the storage array during creation. Instead, when the guest operating system writes to a block for the very first time, the VMkernel intercepts the I/O, writes zeros across the physical block to purge legacy data (enforcing tenant security), and then commits the guest write. This introduces a slight "zero-on-first-write" latency penalty on initial write operations.

2. Thick Provision Eager Zeroed

• Allocation: All physical disk capacity is allocated immediately upon creation.
• Zeroing Behavior: The VMkernel explicitly zeroes out every single physical block on the storage array during disk instantiation. Creating an Eager Zeroed disk takes significantly longer because the entire volume is written with zeros upfront.
• Performance & Use Cases: Because all blocks are pre-zeroed, there is zero latency penalty on first-write operations. Requirements for shared disks, multi-writer use and Fault Tolerance depend on datastore and application support. In particular, WSFC shared-disk support is not established by enabling the multi-writer flag; follow the application-specific supported configuration.

3. Thin Provisioning

• Allocation: Consumes only the physical storage actually written by the guest operating system. A 100 GB thin-provisioned disk initially consumes only a few megabytes of metadata on the datastore.
• Growth Behavior: As the guest OS creates files and commits writes, the virtual disk dynamically expands in increments of the file block allocation size up to the configured 100 GB logical maximum.
• Trade-offs: Delivers maximum storage capacity efficiency and enables overcommitment of physical datastore space. However, thin provisioning carries operational risk: if the physical datastore runs out of actual free space due to uncontrolled thin expansion, all virtual machines with uncommitted writes will be automatically paused by the hypervisor to prevent data corruption.

---

Virtual Disk Provisioning Comparison Matrix

---

Datastore Capacity Expansion: LUN Expansion vs. Extent Spanning

As workloads expand, administrators inevitably need to add capacity to an existing VMFS datastore. vSphere provides two distinct operational methods to accomplish datastore expansion:

1. Growing the Existing Extent (LUN Expansion - Recommended)

In this workflow, the storage administrator expands the size of the existing physical LUN directly on the storage array management console (e.g., expanding LUN 10 from 10 TB to 20 TB):

1. The vSphere administrator triggers a Rescan Storage on the ESXi cluster.
2. In the vSphere Client, navigate to the Datastore > Configure > Device Backing > Increase Datastore Capacity.
3. The administrator selects the backing device and chooses Expand an existing extent.
4. The VMFS partition is dynamically expanded into the newly available contiguous space without interrupting virtual machine execution.

2. Spanning Datastores Across Multiple Extents (Add Extent - Discouraged)

In this workflow, an administrator adds a completely separate, distinct physical LUN (e.g., LUN 20) to an existing datastore formatted on LUN 10. The hypervisor concatenates the two LUNs into a single logical volume spanning up to a maximum of 32 extents (up to 64 TB total):

• The Critical Architecture Flaw: VMFS extents operate as a linear concatenation (similar to JBOD), not a RAID array. There is no parity or data mirroring across extents.
• Disaster Risk: If any single LUN among the 32 spanned extents suffers a catastrophic hardware failure, unrecoverable corruption, or accidental unmapping, the entire VMFS datastore becomes corrupt and inaccessible. Recovering data from the remaining intact extents is extremely complex and frequently impossible without restoring from backups.
• Operational Standard: Production enterprise environments should strictly prohibit extent spanning. Datastores should always be expanded by growing the backing LUN.

Official Reading

Use the official 2V0-16.25 objective guide for scope and Broadcom technical documentation for the installed 9.0 component. This independent lesson was reviewed October 18, 2026; actual deployment support depends on the applicable version and configuration.

Review Takeaways

• Fabric zoning controls initiator-target access, while array mapping/masking controls device visibility.
• VMFS provides coordinated multi-host access to supported block storage.
• VMFS-6 asynchronous reclamation and array free-space reporting operate at different layers.
• Thin, lazy-zeroed thick and eager-zeroed thick disks differ in allocation and zeroing; clustering support must be checked separately.