3V0-23.25 Questions and Answers

The prerequisite is to enable vSAN on the non-vSAN cluster so it can operate as a vSAN compute cluster. A vSAN compute cluster is a vSphere cluster that does not contribute local vSAN capacity, but it has vSAN functionality enabled so it can mount a remote vSAN datastore provided by a vSAN Storage Cluster. The Datastore Management option under the vSAN section appears only when the consuming cluster is prepared for vSAN datastore sharing. Without vSAN enabled in compute-cluster mode, the vSphere cluster remains a conventional VMFS-backed cluster and cannot use the vSAN remote datastore management workflow. The cluster does not need to be in a different VCF Workload Domain, and there is no requirement that the storage cluster maintain exactly 80% free space before the option appears. A fourth host is also not required simply to mount remote vSAN capacity. The key requirement is enabling vSAN capability on the client cluster so it can communicate with and consume the remote ESA datastore. Reference topics: vSAN Compute Cluster, Remote vSAN Datastore, Datastore Management, vSAN Storage Cluster.

In vSAN ESA, the observed three disk stripes are expected behavior for objects using RAID-1, even when the storage policy shows “Number of disk stripes per object = 1.” The vSAN policy rule defines the minimum number of capacity devices across which each replica of an object is striped, and the default value is 1. However, VMware documentation explicitly notes that objects in a vSAN ESA cluster with RAID-0 or RAID-1 configuration have 3 disk stripes, even if the default storage policy defines only 1 disk stripe. Therefore, the three stripes are not caused by site mirroring itself, nor by the VM having three objects. Site mirroring controls placement across the preferred and secondary sites in a stretched cluster, while Failures to tolerate with RAID-1 controls local host/device protection. The behavior is also not evidence that a VM-level policy override exists. The datastore-level policy can still be applied correctly; ESA’s internal RAID-1 object layout uses three stripes as part of its optimized storage architecture. Reference topics: vSAN ESA Default Storage Policy Characteristics, Number of Disk Stripes per Object, RAID-1 Mirroring, vSAN Stretched Cluster Storage Policies.

The required action is to deploy the VMware Live Recovery appliance. In VMware Cloud Foundation 9.0, vSAN Data Protection is powered by VMware Live Recovery and provides local virtual machine protection and remote virtual machine replication for supported vSAN ESA environments. The vSAN Services configuration workflow explicitly states that before vSAN Data Protection can be used, the VMware Live Recovery appliance must be deployed. This appliance provides the data protection control plane required for protection groups, native snapshots, recovery workflows, and replication-based protection. Enabling vSAN advanced options is not sufficient because those settings control cluster behaviors such as repair timers, read locality, thin swap, unmap, and rebalance. Data Services Manager is used for database/data-service lifecycle use cases, not vSAN VM data protection. vSphere Replication can be part of broader site-recovery scenarios, but it is not the required action to enable vSAN Data Protection from the vSAN services workflow. Reference topics: vSAN Data Protection, VMware Live Recovery Appliance, vSAN Services Configuration, Local VM Protection and Replication.

vSAN Stretched Clusters meet the availability-zone requirement by extending a single logical vSAN cluster across two availability zones and using a witness for quorum. This provides rapid recovery from a site or availability-zone failure because workloads remain protected by the stretched topology and vSAN site-failure tolerance. vSAN Storage Cluster addresses the need for scalable, high-performance storage that can grow independently as application capacity requirements increase. In VCF 9.0, a vSAN Storage Cluster is based on vSAN ESA and provides disaggregated storage to vSAN compute or HCI clusters. This design supports storage-dense NVMe-based nodes, high IOPS, low latency, independent capacity scaling, and centralized storage services. Encryption at rest and in transit are native vSAN capabilities that can be enabled on the vSAN-backed storage architecture. vSAN File Service is for file shares, and vSAN iSCSI Target Service is for presenting block LUNs to external initiators; neither is required by the stated application-storage design. vSAN Data Protection is valuable for snapshots and recovery points, but the core architecture requirements are best satisfied by stretched site resilience plus scalable vSAN storage clustering. Reference topics: vSAN Storage Cluster, vSAN Stretched Cluster, vSAN ESA, vSAN Encryption.

Run the esxcli storage nfs list command.

Use vCenter Datastore Performance view to monitor NFS datastore latency, IOPS and throughput.

Create a vCenter performance alarm for “Datastore Latency (NFS)” to trigger when thresholds are exceeded.

The correct monitoring workflow is to verify NFS datastore presentation at the host layer, then use vCenter performance views and alarms for operational monitoring. The esxcli storage nfs list command confirms that the NFS datastore is mounted and visible to the ESX host, which is the first validation point before any performance assessment. vCenter Datastore Performance views provide the correct datastore-level telemetry for latency, IOPS, and throughput, including NFS-backed datastores. Creating a vCenter performance alarm for NFS datastore latency allows proactive alerting when the datastore exceeds the required latency threshold. The esxcli storage core device list command is intended for block storage devices and paths, not NFS datastores. The --verbose NFS option listed here is not the required method for collecting detailed performance metrics in this scenario. VCF Operations Logs is log-focused, not the correct graph source for NFS throughput validation. vSAN Performance Service applies to vSAN performance, not external NFS datastore monitoring. Reference topics: NFS Datastore Monitoring, vCenter Datastore Performance, NFS Host Validation, vCenter Performance Alarms.

The user account used by the application.

The Active Directory used by the application.

The password used by the application.

NFSv4.1 with Kerberos requires identity integration through Active Directory and a valid Kerberos-capable user credential. In vSphere, Kerberos authentication for NFS 4.1 uses Active Directory credentials so ESX can authenticate securely when mounting Kerberos-protected NFS datastores. The required inputs are the Active Directory domain, the user account, and the password associated with that account. The storage guide also states that when several ESX hosts access the same NFS 4.1 datastore, all hosts must use the same Active Directory credentials to ensure consistent access. The Organizational Unit is not the required credential element for datastore mounting. The DNS name of a Kerberos server may be resolved through Active Directory and DNS infrastructure, but it is not one of the required configuration values selected here. A “Kerberos Key Management Server” is not part of the vSphere NFSv4.1 Kerberos datastore configuration model. Therefore, the required options are the application’s user account, its Active Directory, and the account password. Reference topics: NFSv4.1 Datastores, Kerberos Authentication, Active Directory Credentials, Kerberos Security for NFS.

Windows Server Failover Cluster shared disks require coordinated access to shared block storage. vSAN supports Windows Server Failover Clusters by providing SCSI-3 Persistent Reservation support at the virtual disk level, which allows cluster nodes to arbitrate access to a shared disk resource. One supported approach is to use the vSAN iSCSI Target Service, which presents vSAN-backed LUNs to initiators and can be used for clustered workloads that require shared block access. Another supported approach is to configure a shared virtual disk using a VMware Paravirtual SCSI controller with physical bus sharing. Physical bus sharing allows multiple VMs to access the same shared virtual disk in a WSFC configuration where supported. Raw Device Mapping is not the vSAN ESA-native solution for this requirement. NFS v4.1 is a file datastore protocol, not a WSFC shared block disk mechanism. “LSI SCSI controller per disk” does not satisfy the required shared-disk bus sharing configuration. Reference topics: vSAN Support for Windows Server Failover Clusters, SCSI-3 Persistent Reservations, vSAN iSCSI Target Service, Shared VMDK Configuration.

The correct steps are to create an NFS export on the storage array and mount the NFS datastore on each ESX host in the cluster. NFS datastore creation begins on the storage system, where the storage administrator creates and exports the NFS volume or directory with the required access permissions for the ESX hosts. After the export exists, vSphere mounts that export as a datastore. For a clustered VCF workload domain, the datastore must be mounted consistently across all ESX hosts in the cluster so that HA, DRS, vMotion, and VM placement can operate correctly. Mounting the datastore on only one host would create inconsistent datastore accessibility and could prevent workloads from moving or restarting on other hosts. “Attach NFS as a secondary datastore” is not the correct procedural step; the datastore is created and mounted as a vSphere datastore. Configuring vSAN is irrelevant because the workload domain already uses NFS storage and the task is to add another NFS datastore. Reference topics: NFS Datastore Creation, NFS Export, Host Accessibility, VCF Workload Domain Storage Administration.

Seven hosts per availability zone is required for this design. In a vSAN ESA stretched cluster, data components are distributed across two data sites, while a witness site provides quorum. The first requirement is a secondary level of resilience of FTT=2 using RAID-6 erasure coding. RAID-6 requires enough fault domains to place data and parity components while tolerating two failures. The second requirement is more restrictive: vSAN must be able to regain its prescribed level of resilience after a sustained host outage. This means the site must have enough remaining placement capacity to rebuild components and return objects to policy compliance after a host is lost. A six-host site can satisfy the RAID-6 placement minimum, but it does not provide the additional host needed to rebuild cleanly after a sustained host outage. Therefore, the design requires seven hosts in each availability zone. This produces fourteen data hosts across the stretched cluster, plus the witness. Reference topics: vSAN ESA Stretched Cluster Design, Secondary Level of Resilience, RAID-6 Erasure Coding, Availability Zone Host Count.

The support status is based on the VCF 9.0 Principal and Supplemental Storage model. vSAN ESA is supported as principal storage for the Management Domain default cluster, Management Domain additional clusters, and Virtual Infrastructure Workload Domains. A vSAN Storage Cluster is not supported for the Management Domain default cluster, but it is supported as principal storage for Management Domain additional clusters and VI Workload Domains. NFS storage supports principal and supplemental usage when the protocol is NFS v3; the table states “Principal (NFS v3)” and “Supplemental (NFSv3 and NFSv4.1)” across all three domain categories, so NFS v3 maps to Both. iSCSI is supported only as supplemental storage across the Management Domain default cluster, Management Domain additional clusters, and VI Workload Domains. This follows the VCF distinction where principal storage is used during workload domain or cluster creation, while supplemental storage is added after creation for workloads or data-at-rest use cases such as templates, backups, and ISO images. Reference topics: Storage Models, Principal Storage, Supplemental Storage, vSAN ESA, vSAN Storage Cluster, NFS, iSCSI.

vSAN ESA Storage Clusters are the optimal choice because the workload profile is capacity-heavy and benefits from disaggregated storage. The requirement for 2.5 PB of application data, archival workloads, gateways, and development/test applications indicates a need to scale storage capacity independently from compute resources. VMware Cloud Foundation describes a vSAN storage cluster as a disaggregated storage solution based on vSAN ESA. It provides storage resources but not compute resources, and its datastore can be mounted by vSAN compute clusters or vSAN HCI clusters. This model is designed for storage-dense environments where capacity and performance can be expanded without adding unnecessary compute. A standard vSAN ESA HCI cluster is excellent for high-performance workloads, but it scales compute and storage together. vSAN OSA all-flash and hybrid use the older disk-group architecture and are less suitable for this large-capacity, storage-centric design. Therefore, the principal storage recommendation should be vSAN ESA Storage Clusters to meet scalability, performance, and capacity growth requirements. Reference topics: vSAN Storage Cluster, Disaggregated Storage, vSAN ESA, Storage Models.

Four hosts are required to meet the 12 TB usable-capacity requirement after applying the protection policy, data reduction, reserves, and overhead. Each host contributes 8 TB raw capacity from two 4 TB NVMe devices. Three hosts provide 24 TB raw capacity, but once host rebuild reservation, 10% operational reserve, RAID-5 protection overhead, and 25% filesystem/object overhead are considered, the remaining effective usable capacity falls below the required 12 TB target. Four hosts provide 32 TB raw capacity. With vSAN ESA and FTT=1/RAID-5, vSAN uses erasure coding to improve capacity efficiency compared with mirroring. The vSAN sizing guidance states that RAID-5 with FTT=1 provides approximately 75% usable capacity before other reserves and overhead. Host Rebuild Reserve must also be planned so the cluster has enough free capacity to rebuild components after a host failure. After applying the expected 1.5 data reduction ratio and the required reserves, four hosts provide enough usable capacity while three hosts do not. Reference topics: vSAN ESA Capacity Sizing, RAID-5 Erasure Coding, Host Rebuild Reserve, Operations Reserve, vSAN Object Overhead.

In vSAN ESA, each host uses a storage pool instead of the older OSA disk- group model. The question asks what percentage of that host’s local capacity is impacted by the failure of one storage device. Each host has 12 equal-capacity storage devices, and all 12 devices participate in one storage pool. Therefore, one failed device represents one-twelfth of that host’s local pool capacity. One divided by twelve equals approximately 8.3%. RAID-6 with FTT=2 determines object resilience across hosts and fault domains, but it does not change the simple local-capacity fraction represented by a single failed disk on one host. With sufficient cluster resources and policy compliance, vSAN ESA can continue serving data and begin repair or reprotection using remaining capacity. However, the impacted local host capacity is still the failed device’s share of the host storage pool. The correct percentage is therefore 8.3%, not 25%, 50%, or 0%. Reference topics: vSAN ESA Storage Pools, Storage Device Failure, RAID-6 FTT=2, Capacity Impact Calculation.

The correct mapping comes from the VCF 9.0 Principal and Supplemental Storage model. vSAN ESA is supported as principal storage for the Management Domain default cluster, Management Domain additional clusters, and VI Workload Domains. A vSAN Storage Cluster is not supported for the Management Domain default cluster because the initial management cluster requires a standard principal storage model, but it is supported as principal storage for Management Domain additional clusters and VI Workload Domains. Fibre Channel is supported as both principal and supplemental storage across all three domain or cluster categories, allowing either initial cluster creation or later datastore expansion. NFS v4.1 is supplemental-only across these categories. NFS can be principal only when using NFS v3; NFS v4.1 is used as supplemental storage after the domain or cluster exists. These statuses align with VCF’s distinction between principal storage, which is used during workload domain or cluster creation, and supplemental storage, which is added after creation for workloads or data-at-rest use cases. Reference topics: Storage Models, Principal Storage, Supplemental Storage, vSAN ESA, Storage Cluster, Fibre Channel, NFS.

The available custom recovery steps are top-level commands, message prompts, and per-machine commands. VMware Live Site Recovery recovery plans operate like automated runbooks, and administrators can insert custom steps to match business continuity requirements. Broadcom TechDocs states that custom recovery steps can run commands or present messages to the user during a recovery. Command recovery steps are divided into two categories: top-level commands and per-virtual-machine commands. Top-level commands are inserted directly into the recovery plan and run on the VMware Live Site Recovery server. Per-machine commands are associated with individual recovered VMs and run before or after that VM is powered on, depending on placement in the workflow. Message prompts are interactive steps that pause the plan until an operator acknowledges the message, making them useful for manual validation, external approvals, or runbook checkpoints. IP reconfiguration is handled through recovery plan networking and guest customization, not as a custom step type. Writable storage snapshots are part of test recovery/storage behavior, not a custom recovery step. Reference topics: VMware Live Site Recovery Recovery Plans, Creating Custom Recovery Steps, Top-Level Commands, Message Prompts, Per-VM Commands.

Supplemental storage is intended for adding storage capacity to an existing workload domain or cluster after the principal storage has already been deployed. Principal storage is the datastore used during workload domain or cluster creation and is normally used for live workload placement. Supplemental storage can be added later for additional workloads, templates, ISO images, backup data, or other data-at-rest requirements. In this scenario, the administrator specifically needs additional capacity for backup data and ISO images without changing or impacting the principal storage used for production workloads. Attaching additional NFS volumes or iSCSI datastores satisfies this requirement because both can be used as supplemental storage options in VCF. Migrating the Management Domain storage is unrelated and unnecessary. Increasing the existing VMFS principal storage allocation does not provide the requested separation between production and backup or ISO storage. Replacing all existing datastores with NVMe devices would be disruptive and does not match the supplemental-storage use case. Reference topics: Principal Storage, Supplemental Storage, NFS Supplemental Storage, iSCSI Supplemental Storage, Day-2 Storage Expansion.

The two major contributors are RAID overhead and Operational Reserve. With the default policy set to FTT=1 using RAID-1 mirroring, vSAN stores two copies of protected data. The capacity planning guidance states that when Failures to tolerate is set to 1 failure with RAID-1 mirroring, virtual machines can use about 50 percent of raw capacity because each object consumes mirrored space. This is the largest capacity-impacting factor. The second contributor is Operational Reserve, which reserves capacity for vSAN internal operations such as policy changes, rebalancing, object movement, and other transient storage activities. Even when Host Rebuild Reserve is not activated, vSAN capacity monitoring still accounts for the operations threshold/reserve needed to keep the cluster functional during internal activity. Encryption overhead is typically not the primary reason for a 20% capacity difference. Host upgrade overhead is not a vSAN capacity category. VM swap can consume capacity, but it does not normally account for most unavailable raw capacity compared with RAID mirroring and operational reservation. Reference topics: vSAN Capacity Planning, RAID-1 FTT=1 Capacity Impact, Operations Reserve, Reserved Capacity.