VMware 5V0-22.23 VMware vSAN Specialist v2 Exam Practice Test

When adding a disk to a host that was previously used in a decommissioned vSAN cluster, the disk may still have some vSAN metadata partitions that prevent it from being recognized by disk management. To resolve this issue, the disk partitions need to be deleted using either ESXCLI or partedUtil commands. This will erase all data on the disk and make it available for use in disk management. References: VMware vSAN Specialist v2 EXAM 5V0-22.23, page 21

A possible cause of high latency on the vSAN cluster is that there is congestion in one or more disk groups. Congestion is a measure of how busy the storage devices are in handling I/O requests. When congestion is high, it means that the storage devices are overloaded and cannot process the requests fast enough, resulting in increased latency and reduced throughput. Congestion can be caused by various factors, such as insufficient cache capacity, disk failures, network issues, or heavy workload. The other options are not likely to cause high latency on the vSAN cluster. The Virtual Machines can use PVSCSI controllers without affecting latency, as they are optimized for high performance. Erasure Coding is a space efficiency feature that does not impact latency significantly. Jumbo frames are not required for vSAN, and enabling them does not guarantee lower latency. References: vSAN Performance Monitor; [vSAN Congestion Explained]

To configure vSAN Direct, the administrator must meet two requirements: a valid vSAN license for the vSAN cluster and unclaimed disks in the hosts for vSAN Direct. A vSAN license is required to enable vSAN features and services, including vSAN Direct. Unclaimed disks are local storage devices that are not used by vSAN or any other service, and can be claimed by vSAN Direct to create datastores for persistent storage. The other options are not requirements for vSAN Direct. HA is an optional feature that can be enabled on any cluster, but is not specific to vSAN Direct. A dedicated network for vSAN Direct is not necessary, as vSAN Direct uses the same network as vSAN. An integration with vSAN File Services is not required, as vSAN Direct does not provide file shares, but block storage. References: Set Up vSAN Direct for vSphere with Tanzu; vSAN Licensing Guide

vSAN will use a 4+1 RAID-5 data placement scheme with parity will be used is the correct answer because vSAN 8 ESA uses adaptive RAID-5 erasure coding that depends on the number of hosts in the cluster. If the cluster has 6 or more hosts, vSAN will use a 4+1 RAID-5 scheme, where the data is written as a stripe of 4 data bits and 1 parity bit across 5 hosts. This provides a failure tolerance of 1 (FTT=1) and a space efficiency of 1.25x. If the cluster has less than 6 hosts (3 to 5), vSAN will use a 2+1 RAID-5 scheme, where the data is written as a stripe of 2 data bits and 1 parity bit across 3 hosts. This also provides a failure tolerance of 1 (FTT=1) but a space efficiency of 1.5x. In this case, the cluster has 5 hosts, so vSAN will use the 4+1 RAID-5 scheme.

The other options are incorrect for the following reasons:

• A, vSAN will use a 2+1 RAID-5 data placement scheme with parity will be used, is incorrect because vSAN will only use this scheme if the cluster has less than 6 hosts but more than 2 hosts. In this case, the cluster has 5 hosts, so vSAN will use the 4+1 RAID-5 scheme.
• B, RAID 5 will provide an FTT=2 level of protection in this case, is incorrect because RAID 5 can only provide an FTT=1 level of protection, regardless of the number of hosts or the data placement scheme. To achieve an FTT=2 level of protection, vSAN would need to use RAID 6 erasure coding, which requires at least 6 hosts in the cluster.
• D, vSAN will spread the components across all of the disk groups, is incorrect because vSAN will not necessarily spread the components across all of the disk groups in the cluster. vSAN will only spread the components across as many disk groups as needed to meet the storage policy requirements and to balance the load and capacity. In this case, vSAN will only need to spread the components across 5 disk groups for each stripe of RAID-5 data. References:
• VMware vSAN Specialist v2 Exam Preparation Guide, page 11
• Adaptive RAID-5 Erasure Coding with the Express Storage Architecture in vSAN 8

Two characteristics of the vSAN Data-At-Rest Encryption (DARE) are that it is Software Defined and works independently of the Cache or Capacity drives installed on the Nodes, and that it continues to operate unaffected during downtime on vCenter Server. DARE is a feature that encrypts all data stored on vSAN disks using AES-256 XTS mode. It does not require Self-Encrypting Drives (SEDs) to work, as it uses software-based encryption keys that are generated by an external Key Management Server (KMS) or a vSphere Native Key Provider. DARE also does not depend on the type or size of the disks used in the vSAN cluster, as it encrypts data after all other processing, such as deduplication and compression, is performed. DARE can function even when the vCenter Server is offline or unavailable, as it uses key persistence to store the encryption keys on the ESXi hosts or in a Trusted Platform Module (TPM). The hosts can access the keys without contacting the KMS or the vCenter Server. The other options are notcorrect, as they do not describe DARE accurately. DARE does not need to be enabled together with the vSAN Data-In-Transit encryption, as they are independent features that can be enabled or disabled separately. Data-In-Transit encryption encrypts data that is transmitted between hosts in a vSAN cluster using secure sockets layer (SSL) certificates. DARE is supported on Stretched Cluster environments, as it can encrypt data across multiple sites using site affinity rules. 

Adding one more disk group per host with the same configuration and adding an ESXi host with identical device configuration are the two methods that the vSAN administrator should use to meet the goal of increasing capacity and performance with the least amount of impact. Adding one more disk group per host will increase the raw storage capacity by 20% and also improve the performance by distributing the I/O load across more cache devices and disk groups. Adding an ESXi host with identical device configuration will increase the raw storage capacity by 25% and also improve the performance by adding more compute and network resources to the cluster. Both methods can be done without disrupting any ongoing operations or requiring any data evacuation or resynchronization.

The other options are incorrect for the following reasons:

• Replacing all capacity devices with a similar larger device is incorrect because it will not increase the performance and will have a significant impact on the cluster. Replacing the capacity devices requires deleting the disk groups, which will erase all data on them and trigger a resynchronization of the affected objects. This can be disruptive and time-consuming, and also introduce additional network and disk traffic.
• Replacing all cache devices with a larger device is incorrect because it will not increase the capacity and will have a significant impact on the cluster. Replacing the cache devices also requires deleting the disk groups, which will have the same drawbacks as replacing the capacity devices. Moreover, increasing the cache size may not improve the performance significantly, as vSAN OSA uses afixed cache ratio of 70% for write buffer and 30% for read cache, regardless of the cache device size.
• Adding faster cache devices is incorrect because it will not increase the capacity and will have a significant impact on the cluster. Adding faster cache devices also requires deleting the disk groups, which will have the same drawbacks as replacing the cache devices. Furthermore, adding faster cache devices may not improve the performance significantly, as vSAN OSA uses a fixed cache ratio of 70% for write buffer and 30% for read cache, regardless of the cache device speed. References:
• VMware vSAN Specialist v2 Exam Preparation Guide, page 10
• Expanding a vSAN Cluster

vSphere High Availability is the correct answer because it meets the requirements of making the virtual machine available quickly after a failure occurs and minimizing administrative effort. vSphere HA monitors the health and availability of the hosts and virtual machines in a cluster and automatically restarts any failed virtual machines on other hosts within minutes. vSphere HA also supports proactive HA, which can migrate virtual machines from hosts that are about to fail or have degraded performance. vSphere HA is easy to configure and manage, as it only requires enabling HA on the cluster level and setting some basic policies and options. Distributed Services Engine,Fault Tolerance, and vSphere Distributed Resource Scheduler are not valid or optimal solutions for this scenario. Distributed Services Engine is a new feature in vSphere 7 that provides network services such as firewalling, load balancing, routing, and NAT for virtual machines and containers. It does not directly affect the availability or recovery of virtual machines after a failure. Fault Tolerance provides continuous availability for virtual machines by creating a secondary copy of the virtual machine that runs in lockstep with the primary copy on another host. If the primary copy fails, the secondary copy takes over without any interruption or data loss. However, Fault Tolerance has some limitations and overheads, such as requiring dedicated network bandwidth, supporting only one vCPU per virtual machine, and consuming twice as much CPU and memory resources as a single virtual machine. Fault Tolerance also requires more administrative effort than vSphere HA, as it needs to be enabled and configured for each individual virtual machine. vSphere Distributed Resource Scheduler is a feature that balances the workload and resources across a cluster by automatically migrating virtual machines based on their demand and priority. It does not directly affect the availability or recovery of virtual machines after a failure, although it can work together with vSphere HA to find optimal hosts for restarting failed virtual machines. References:

• [VMware vSAN Specialist v2 Exam Preparation Guide], page 11
• vSphere Availability
• Distributed Services Engine
• vSphere Distributed Resource Scheduler

To reduce the amount of vSAN datastore capacity the virtual machines will consume, the vSAN administrator should change the FTT rule to “1 Failure - RAID-1 (Mirroring)”, and select “Now” for Reapply to VMs. This action will reduce the number of replicas for each object from three to two, and thus free up some space on the vSAN datastore. The other options are not correct, as they will not reduce the capacity consumption. Modifying the FTT rule to “2 Failures - RAID-5 (Erasure Coding)” will not work for a hybrid vSAN cluster, as erasure coding is only supported for all-flash clusters. Adding the “Flash read cache reservation” rule to the storage policy, and setting to 0% will not affect the capacity layer, as it only controls the amount of flash cache reserved for each object. Disabling Operations reserve and Host rebuild reserve and clicking “Apply” will not change the actual space used by the objects, as these reserves are only logicalsettings that affect how much free space is reported by vSAN. References: 1, page 9; , section 4.3

To build a vSAN ESA cluster with RAID-5/FTT 1 adaptive storage policy, the absolute minimum number of hosts that need to be part of that vSAN ESA cluster is 3. This is because the vSAN ESA supports a new RAID-5 erasure coding scheme in a 2+1 configuration, which writes the data in a VM as a stripe consisting of 2 data bits and 1 parity bit, across a minimum of 3 hosts. This scheme can tolerate a single host failure (FTT=1) while consuming 1.5x the capacity of the primary data. This scheme is suitable for smaller vSAN clusters that want to reduce capacity usage without compromising performance12 References: 1: VMware vSAN Specialist v2 ExamPreparation Guide, page 15 2: Adaptive RAID-5 Erasure Coding with the Express Storage Architecture in vSAN 8 3

Two actions that would cause some objects to be currently resyncing are:

• A change to the storage policy is applied to the objects. This action triggers a resynchronization of objects to make them compliant with the new policy settings, such as FTT, RAID level, stripe width, etc. The resynchronization process copies data from one host to another to create or update replicas or parity segments.
• A host failure occurs in the cluster. This action causes some objects to become non-compliant with their storage policy, as they lose one or more replicas or parity segments due to the host failure. The resynchronization process rebuilds the missing components on other hosts in the cluster to restore compliance and availability.References: : VMware vSphere Storage Guide, page 129 : Monitor the Resynchronization Tasks in the vSAN Cluster 1 : VMware vSAN Specialist v2 Exam Preparation Guide, page 13

To create an image using vSphere Lifecycle Manager, the mandatory requirement is to specify the ESXi version. An image is a collection of software components that define the desired state of hosts in a cluster. An image must include at least one ESXi version component, which determines the base hypervisor software for the hosts. Optionally, an image can also include other components, such as vendor add-ons, firmware and drivers add-ons, or custom components. The other options are not correct. A component is a generic term for any software element that can be included in an image, but it is not a specific type of component. A firmwareand drivers add-on is an optional component that provides firmware and drivers updates for hardware devices on the hosts. A vendor add-on is an optional component that provides vendor-specific software for the hosts. References: About Images; Create an Image

The host rebuild reserve is a feature that allows vSAN to reserve space in the cluster for vSAN to be able to repair in case of a single host failure. This reservation is set to one host worth of capacity, which means that if one host in the vSAN cluster fails and no longer contributes storage, there is still sufficient capacity remaining in the cluster to rebuild and re-protect all vSAN objects. This feature prevents the creation of new VMs or powering on VMs if such operations consume the reserved space. By default, the host rebuild reserve is disabled, but it can be enabled in the vSAN Services configuration. The other options are not related to the hostrebuild reserve. References: vSAN Capacity Management in v7.0U1; Configure Reserved Capacity

To implement HCI mesh between two clusters on vSAN that are located in geographically separate sites, the vSAN administrator should consider the following requirements:

• Either Layer 2 or Layer 3 communications can be used. HCI mesh supports both Layer 2 and Layer 3 network configurations, as long as the network latency and bandwidth requirements are met3
• The configuration must meet the same latency and bandwidth requirement as local vSAN. HCI mesh requires a network latency of less than or equal to 5 ms RTT between any two hosts in the participating clusters, and a network bandwidth of at least 10 Gbps for the vSAN network vmkernel port3 References: 3: VMware vSAN Specialist v2 Exam Preparation Guide, page 15

To monitor the performance of vSAN File Services, the vSAN administrator must enable both the vSAN File Services and the vSAN Performance Service. The vSAN File Services provides SMB file shares to host clients, while the vSAN Performance Service collects and analyzes performance statistics and displays them in the vSphere Client. The other services are not related to vSAN File Services performance monitoring. References: VMware vSAN Specialist v2 EXAM 5V0-22.23, page 9, Objective 7.4; [vSAN File Services]; [vSAN Performance Service]

When a host in a vSAN stretched cluster goes offline, vSAN will use Adaptive Resync to recalculate the quorum on an object. Quorum is the minimum number of votes that an object needs to be available. For example, a RAID-1 object with two data components and one witness component needs two votes out of three to be available. If one data component goes offline, the object still has quorum and is available. However, if both data components go offline, the object loses quorum and is unavailable. Adaptive Resync will adjust the quorum requirement based on the availability of components and fault domains. For example, if one fault domain goes offline, Adaptive Resync will lower the quorum requirement to one vote out of two, so that the object can remain available with one data component and one witness component. References: VMware vSAN Specialist v2 EXAM 5V0-22.23, page 18

To make sure that Skyline online health will work for vSAN, two requirements must be met: enable CEIP and join the program, and have a working Internet connection. CEIP stands for Customer Experience Improvement Program, which is a voluntary program that collects anonymous product usage data from customers who participate in it. By enabling CEIP and joining the program, customers can benefit from Skyline online health, which provides proactivenotifications and recommendations for software and hardware issues based on VMware Analytics Cloud. A working Internet connection is also required for Skyline online health to communicate with VMware Analytics Cloud and receive online notifications. The other options are not requirements for Skyline online health. References: About the vSAN Skyline Health; Skyline Health

To protect a virtual machine against a disk or disk group failure, the storage policy must have a failure tolerance method (FTM) of RAID-1 or RAID-6 and a failure to tolerate (FTT) value of at least 1. RAID-1 mirrors the data across multiple disk groups, while RAID-6 uses erasure coding to stripe the data and parity information across multiple disk groups. RAID-5 is not suitable for this scenario, as it can only tolerate one disk failure per stripe. FTT 2 or 3 would require more disk groups than available in the cluster. Therefore, the correct options are C and E. References: 1, page 8; 2, section 3.1

The maximum amount of capacity disks an administrator can have in disk groups on a single vSAN OSA host is 35. This is because a single host can have up to five disk groups, and each disk group can have up to seven capacity disks. Therefore, the maximum number of capacity disks per host is 5 x 7 = 35. The other options are not correct, as they are lower than the maximum number of capacity disks per host. References: Designing and Sizing vSAN Storage; [vSAN ReadyNode Hardware Guidance]

Utilizing Network I/O Control and isolating vSAN traffic in a VLAN are the two actions that should be taken to configure the new vSAN cluster to meet the requirements. Network I/O Control allows the vSAN administrator to create network resource poolsand assign bandwidth shares or reservations to different traffic types, such as vSAN, vMotion, or management. This ensures that vSAN traffic has guaranteed bandwidth during contention and can achieve better performance and availability. Isolating vSAN traffic in a VLAN enhances the security of the cluster by preventing unauthorized access or interference from other network segments. It also simplifies the network configuration and management by reducing the broadcast domain and avoiding IP address conflicts. Creating static routes between the vSAN hosts, using IOPS Limit rules in storage policies, and enabling jumbo frames are not necessary or recommended actions for this scenario. Static routes are not required for vSAN communication, as vSAN uses multicast or unicast depending on the version and configuration. IOPS Limit rules are used to limit the IOPS allocated to an object, which can degrade the performance and latency of the application. Jumbo frames can improve the network efficiency and throughput, but they are not mandatory for vSAN and require consistent configuration across all network devices. References:

• Network I/O Control
• vSAN Network Design Guide

To upgrade the complete vSAN cluster as a single task, including firmware and drivers for its hardware, the vSAN administrator should select Remediate All through vLCM to upgrade all hosts in the cluster. This option allows the administrator to apply the image created by vLCM to all hosts in the cluster in a single operation, without having to manually remediate each host individually. The other options are not correct, as they do not perform the upgrade of the vSAN cluster as a single task. Placing all hosts in the vSAN cluster into Maintenance Mode is not necessary, as vLCM will automatically place each host into Maintenance Mode before applying the image. Staging the upgrade of the vSAN cluster through vLCM is only a preparatory step that downloads the image components to each host, but does not apply them. Manually remediating one host at a time in the vSAN cluster is not efficient, as it requires more user intervention and time. References: vSphere Lifecycle Manager (vLCM) on HPE; Lifecycle Management with vLCM in vSAN 7 Update 1

The reason why the vSAN administrator cannot find any vSAN performance statistics on the cluster summary page is that the vSAN performance service is not enabled. The vSAN performance service is a feature that collects and analyzes performance metrics and displays them in graphical charts in vCenter. The vSAN performance service must be turned on manually for each vSAN cluster, as it is not enabled by default. The other options are not correct. The integration of vRealize Operations Manager with the vSAN cluster is not required to view vSAN performance statistics, as they are available in vCenter. The administrator’s permissions on the cluster level do not affect the visibility of vSAN performance statistics, as they are accessible to any user who can view the cluster. vSAN performance statistics are not only available via CLI, as they can also be viewed in vCenter using the vSAN performance service. References: About the vSAN Performance Service; Enable or Disable the Performance Service