2V0-21-23 Practice Questions

The "vSphere HA virtual machine failover failed" alarm is triggered when vSphere High Availability determines there are insufficient resources in the cluster to fail over a virtual machine. Removing a host for maintenance reduced the cluster's available resources, triggering this condition. After the host was re-added, the resource constraint was resolved. However, the alarm state does not automatically clear. The administrator must manually intervene to clear the alarm. The "Reset to Green" action is the correct procedure to manually override the alarm's status and return it to normal (green), signifying that the underlying issue has been resolved.

A. Ignore: This is not a formal action in the vSphere Client to clear an alarm; it would leave the system in a persistent warning state.

C. Acknowledge: Acknowledging an alarm only confirms that an administrator has seen it. It does not clear the alarm or change its color status from warning to green.

D. Disable: Disabling the alarm is a permanent configuration change that would prevent this specific alarm from ever triggering again, which is not the appropriate response to a resolved, temporary issue.

1. VMware vSphere Product Documentation

"vSphere Monitoring and Performance" (for vSphere 8.0): In the section "Acknowledge or Reset a Triggered Alarm

" the documentation states

"You can reset the alarm to clear it and return it to its normal state... Resetting an alarm also clears any acknowledgment for the alarm." This directly supports using "Reset to Green" to clear a resolved alarm.

2. VMware Knowledge Base Article 2004802

"'vSphere HA virtual machine failover failed' alarm in vCenter Server": This article explains the cause of the specific alarm in the question

noting it is triggered by insufficient failover capacity. It confirms that after resolving the underlying resource issue (like re-adding a host)

the alarm must be manually cleared. The procedure described is functionally identical to "Reset to Green".

3. VMware vSphere Product Documentation

"vSphere Availability" (for vSphere 8.0): The section on "vSphere HA Admission Control" explains the conditions that lead to failover resource constraints. This provides the context for why removing a host would trigger the alarm

and implicitly

why re-adding it resolves the condition that needs to be manually cleared.

The scenario describes a strict software licensing requirement where the virtual machines app01 and app02 are permitted to run only on a specific subset of hosts (esx11, esx12, esx13). This requires a mandatory, or "hard," affinity rule. The correct procedure is to first group the relevant objects: create a VM group for app01 and app02, and a host group for esx11, esx12, and esx13. Then, a "required" (must run on) VM-Host affinity rule must be created to bind the VM group to the host group. This ensures that vSphere DRS will never place or migrate these VMs to any hosts outside the specified group, thereby enforcing the licensing constraint.

A. This is incorrect because it groups all hosts, not just the licensed ones, and a VM-VM anti-affinity rule only separates VMs from each other; it does not restrict them to specific hosts.

B. A VM-VM affinity rule attempts to keep the specified VMs on the same host. This does not address the core requirement of restricting the VMs to a specific group of licensed hosts.

D. A "preferential" (should run on) rule is a soft constraint. DRS will try to keep the VMs on the specified hosts but can move them to other hosts (e.g., esx14) if necessary, which would violate the strict licensing terms.

1. VMware vSphere Documentation (vSphere 8.0)

vSphere Resource Management

"VM-Host Affinity Rules".

The documentation states

"A required rule (designated by 'must') specifies that the virtual machines in a VM group can run only on the hosts in the associated host group... Required rules are useful for licensing and compliance purposes." This directly supports the use of a required rule for licensing scenarios.

2. VMware vSphere Documentation (vSphere 8.0)

vSphere Resource Management

"Create a VM-Host Affinity Rule".

Step 4 of the procedure outlines creating the VM and Host groups. Step 6 details selecting the rule type

where the options are "Must run on hosts in group" (required) and "Should run on hosts in group" (preferential). This confirms the two-step process described in the correct answer.

3. VMware vSphere Documentation (vSphere 7.0)

vSphere Resource Management

"Using Affinity Rules".

This guide explains

"VM-Host affinity rules are useful for virtual machines that must run on hosts with specific configurations for licensing or hardware requirements." It further clarifies that "must" rules are mandatory

while "should" rules are preferential

reinforcing that a strict licensing requirement mandates a "must" or "required" rule.

To grant a single user specific permissions without affecting others, the principle of least privilege must be applied. The correct procedure involves two distinct steps. First, a new custom role must be created that contains only the necessary privileges for snapshot management (e.g., Create, Remove, Revert). This isolates the required permissions. Second, a new permission must be assigned on the specific virtual machine. This assignment links the specific user (the "who") to the newly created custom role (the "what") on the target VM (the "where"). This method ensures that only the intended user receives the new permissions, and no other users or groups are affected.

A. Add the user to the VMUsers group and leave the permissions on the virtual machine object unchanged.

This grants excessive permissions from the 'Virtual Machine Power User' role, violating the principle of least privilege.

C. Edit the Read Only role to add the Virtual Machine Snapshot Management privileges.

Modifying a default role is not best practice and would grant snapshot permissions to every user and group assigned the 'Read Only' role.

E. Add a new permission on the virtual machine object selecting the VMViewers group and the new custom role.

This would grant snapshot permissions to the entire VMViewers group, not just the single user as required by the task.

1. VMware vSphere Documentation

vSphere Security 7.0

"Create a Custom vCenter Server Role": This official guide details the process for creating a new role. It states

"You can create custom roles to grant sets of privileges that are tailored to the needs of a user or group of users." This supports creating a specific role for snapshot management (Answer D).

Source: VMware vSphere 7.0 Documentation

com.vmware.vsphere.security.doc

Section: "Create a Custom vCenter Server Role".

2. VMware vSphere Documentation

vSphere Security 7.0

"Add a Permission to an Inventory Object": This document outlines the procedure for assigning permissions. The process involves selecting the inventory object (the VM)

adding a permission

and then selecting the specific user and the appropriate role. This directly supports assigning the new custom role to the single user on the VM (Answer B).

Source: VMware vSphere 7.0 Documentation

com.vmware.vsphere.security.doc

Section: "Add a Permission to an Inventory Object".

3. VMware vSphere Documentation

vSphere Security 7.0

"Default Roles and Their Privileges": This section confirms that default roles like 'Read Only' cannot be edited. It states

"You cannot edit the privileges for the default roles." This directly invalidates option C. It also shows that the 'Virtual Machine Power User' role contains many privileges beyond snapshot management

making option A a violation of least privilege.

Source: VMware vSphere 7.0 Documentation

com.vmware.vsphere.security.doc

Section: "Default Roles and Their Privileges".

The primary goal is to keep the two domain controller VMs on separate hosts to ensure high availability, but critically, this must not prevent maintenance operations. In a two-node cluster, a strict ("must") anti-affinity rule would block a host from entering maintenance mode, as DRS would be unable to move its VM to the only other available host without violating the rule.

A "should" rule provides the necessary flexibility. By creating two "Should run Virtual Machines to Hosts" anti-affinity rules (e.g., DC1 should not run on Host B, and DC2 should not run on Host A), the administrator instructs DRS to keep the VMs separate during normal operation. However, DRS is permitted to violate this preferential rule when necessary, such as evacuating a host for maintenance.

A. A 'Must run' rule is too restrictive. It would prevent a host from entering maintenance mode, as DRS cannot violate a "must" rule.

B. A 'Virtual Machines to Virtual Machines' anti-affinity rule is a "must" rule by definition and would block maintenance operations in a two-node cluster scenario.

C. A dependency rule is a vSphere HA setting that dictates the startup order of virtual machines after a host failure, not their placement for resource balancing.

1. VMware vSphere 8.0 Documentation

"vSphere Resource Management"

PDF

Page 80

"Behavior of DRS with Affinity Rules":

"DRS does not evacuate a virtual machine from a host entering maintenance mode if doing so violates a 'must' affinity rule." This directly supports why options A and B are incorrect.

"DRS might violate a 'should' rule in order to evacuate a virtual machine from a host entering maintenance mode." This supports the choice of a "should" rule (Option D) as the correct solution.

2. VMware vSphere 8.0 Documentation

"vSphere Resource Management"

PDF

Page 80

"VM-VM Affinity and Anti-Affinity Rules":

"VM-VM affinity and anti-affinity rules are 'must' rules." This confirms that the rule type in option B is a "must" rule and therefore unsuitable for this scenario.

3. VMware vSphere 8.0 Documentation

"vSphere Resource Management"

PDF

Page 79

"VM-Host Affinity Rules":

"You can create two types of VM-Host affinity rules

'must' rules (required) and 'should' rules (preferential)." This confirms the existence and purpose of the rule type described in option D.

The restore process for a vCenter Server from a file-based backup is initiated using the vCenter GUI Installer, which is run from the vCenter Server ISO file. This method is specifically designed for disaster recovery scenarios, such as a failed upgrade, where the existing vCenter Server is no longer operational. The installer provides a "Restore" workflow that first deploys a new vCenter Server appliance and then populates it with the configuration and data from the selected backup file.

A. The Direct Console User Interface (DCUI) is a low-level interface for basic network configuration and troubleshooting of the appliance; it lacks restore functionality.

B. The vCenter Management Interface (VAMI) is used to configure backups and manage the running appliance, but it cannot be used to perform a restore when the vCenter is non-functional.

C. The vSphere Client is the management interface for the vSphere environment. It is dependent on a functional vCenter Server and would be inaccessible in a failure scenario.

1. VMware vSphere 7.0 Documentation

"vCenter Server Installation and Setup" Guide.

Section: "Restore a vCenter Server from a File-Based Backup"

Content: The guide explicitly states

"You can restore a vCenter Server instance from a file-based backup by using the GUI installer of the vCenter Server appliance." It then details the procedure

which begins with running the installer from the ISO and selecting the "Restore" option.

2. VMware vSphere 8.0 Documentation

"vCenter Server Installation and Setup" Guide.

Section: "Restore vCenter from a File-Based Backup"

Content: This document confirms the procedure for a newer version: "To restore a vCenter instance from a file-based backup

you must deploy a new vCenter appliance by using the GUI installer... In the vCenter installer

click Restore." This reinforces that the GUI installer is the correct tool.

The primary challenge is ensuring vMotion compatibility between hosts with different CPU generations (Intel Skylake and Intel Ice Lake). Enhanced vMotion Compatibility (EVC) is the VMware feature designed specifically to address this. By enabling EVC on the existing cluster, a common CPU feature baseline (in this case, the Skylake generation) is established. When the new Ice Lake hosts are added, they will conform to this baseline, masking their newer features. This allows virtual machines to migrate freely between any of the six hosts using vMotion without downtime, as all hosts will present an identical CPU instruction set to the guest operating systems. This approach is non-disruptive and directly meets all stated requirements.

A. Creating a new cluster and moving all hosts is an unnecessarily disruptive process that could lead to downtime, violating a key requirement.

B. This option fails to create the required single, six-host cluster and does not solve the underlying CPU compatibility issue for the entire environment.

D. vSphere High Availability (HA) is a feature for restarting virtual machines after a host failure; it does not address vMotion compatibility across different CPU types.

1. VMware vSphere Documentation

"vCenter Server and Host Management" guide for vSphere 7.0

Section: "Enhanced vMotion Compatibility (EVC)".

This section states

"EVC ensures that all hosts in a cluster present the same CPU feature set to virtual machines

even if the actual CPUs on the hosts are different. Using EVC prevents vMotion migrations from failing because of incompatible CPUs." This directly supports the use of EVC to solve the problem described.

2. VMware vSphere Documentation

"vCenter Server and Host Management" guide for vSphere 7.0

Section: "Enable EVC on an Existing Cluster".

This section outlines the procedure

confirming that EVC can be enabled on a running cluster. For the process to be non-disruptive to running VMs

the EVC mode must be a superset of the feature set of the running VMs' host. Since the initial hosts are all Skylake

setting the EVC mode to "Intel 'Skylake' Generation" will not affect the running VMs

thus meeting the no-downtime requirement.

3. VMware Knowledge Base Article 1003212

"Enhanced vMotion Compatibility (EVC) processor support".

This document provides a detailed matrix of supported processors and their corresponding EVC baselines. It confirms that both Intel Skylake and Intel Ice Lake CPUs are supported by EVC and can coexist in a cluster by setting the EVC mode to the level of the oldest processor generation

which is "Intel 'Skylake' Generation" in this scenario.

vSphere Distributed Switches (VDS) offer advanced, centralized networking features that are not available on vSphere Standard Switches (VSS). Port mirroring allows for sending copies of network packets to a destination for analysis, a critical tool for monitoring and troubleshooting. NetFlow provides detailed IP traffic flow statistics for performance monitoring and capacity planning. The ability to centrally back up and restore the entire switch configuration simplifies management and disaster recovery. These capabilities are inherent to the VDS architecture, which is managed at the vCenter Server level across all associated hosts.

A. 802.1Q tagging: This is a standard VLAN tagging mechanism supported by both vSphere Standard Switches and vSphere Distributed Switches for network segmentation.

E. IPv6 support: Both switch types operate at Layer 2 and are transparent to Layer 3 protocols; management interfaces (vmknics) on both can be configured with IPv6 addresses.

F. IPv4 support: Similar to IPv6, both switch types fully support IPv4 traffic and management interface configurations.

---

1. VMware vSphere Documentation (vSphere 8.0)

vSphere Networking

"Comparing vSphere Standard Switches and vSphere Distributed Switches": This official guide includes a feature comparison table. It explicitly lists "Port mirroring

" "NetFlow

" and "Backup and restore network configuration" as features available only on vSphere Distributed Switches. It also shows "802.1q tagging" and "IPv6" as being available on both switch types.

2. VMware vSphere Documentation (vSphere 8.0)

vSphere Networking

"Port Mirroring": This section details the configuration of port mirroring sessions and states

"You can configure port mirroring on a vSphere Distributed Switch to mirror a distributed port's traffic to other distributed ports or specific uplinks." This confirms it as a VDS feature.

3. VMware vSphere Documentation (vSphere 8.0)

vSphere Networking

"Monitor Network Flow with vSphere Distributed Switch": This document describes the NetFlow feature

stating

"You can configure NetFlow on a vSphere Distributed Switch to monitor IP traffic that flows through the switch." This confirms NetFlow is specific to VDS.

4. VMware vSphere Documentation (vSphere 8.0)

vSphere Networking

"Export

Import

and Restore vSphere Distributed Switch Configurations": This section provides instructions for these management tasks

confirming that configuration backup and restore is a native feature of the vSphere Distributed Switch.

To address the issue, the administrator must first segregate the different workloads to manage their resources independently. Creating sibling resource pools—one for Production and one for Test—is the standard method for partitioning cluster resources for different service levels.

Once the workloads are separated, the administrator can guarantee memory for the Production VMs. A memory reservation provides a guaranteed minimum amount of physical RAM to a resource pool or virtual machine, even during periods of high contention. Setting a reservation on the Production resource pool ensures its VMs receive their required memory, fulfilling the requirement.

A. Shares define relative priority for resources during contention but do not provide a hard guarantee of a specific memory amount.

C. This is imprecise. The correct approach is to create sibling pools for each workload, not just a single "parent" pool for one.

E. Placing the Test VMs in a child resource pool under the Production pool is an incorrect hierarchy for separating peer workloads.

1. VMware vSphere Documentation

"vSphere Resource Management

" for vSphere 8.0

Chapter 3

"Resource Allocation Settings

" Section: "Reservations."

This section states: "A reservation specifies the guaranteed minimum allocation for a virtual machine... The server allows you to power on a virtual machine only if there are enough unreserved resources to satisfy the reservation of the virtual machine." This confirms that reservations are the mechanism for guaranteeing resources.

2. VMware vSphere Documentation

"vSphere Resource Management

" for vSphere 8.0

Chapter 2

"Managing Resource Pools

" Section: "Create a Resource Pool."

The documentation explains: "Resource pools can be grouped into hierarchies. You can create a resource pool as a child of a host

cluster

or another resource pool." The common use case described is creating sibling pools under a cluster to isolate different business units or

in this case

workload types (Production vs. Test).

3. VMware vSphere: Install

Configure

Manage [V8] - Official Courseware

Module 10: "Using Resource Pools."

This courseware details the best practice of creating sibling resource pools to manage resources for different classes of service. It explicitly contrasts shares (for priority) with reservations (for guarantees)

stating that reservations are used to ensure that critical virtual machines always have sufficient memory.

The browser error shows that the client cannot resolve the host name.

1) A forward (A) record that maps esxi101.corp.local → 172.16.10.101 must exist on the corporate DNS servers so the client can translate the FQDN.

2) ESXi itself must know where to send DNS queries and advertise its correct host and domain names; therefore its Management Network DNS settings must be pointed at the corporate DNS servers.

3) Because no DHCP service is available, the Management Network needs a manually assigned, static IPv4 address (172.16.10.101/24) so that the A-record has a reachable target.

These three steps are the minimum required to log in with the FQDN and finish host configuration.

D. A single NIC is fully supported for the Management Network; additional adapters are optional for redundancy, not name-resolution.

E. VLAN tagging may or may not be needed (depends on switch configuration); it is not inherently required for DNS/FQDN reachability.

F. IPv6 settings do not affect IPv4 DNS resolution or the ability to reach the host by its IPv4 FQDN.

1. VMware vSphere Installation and Setup 7.0

“Configure the Management Network – Set Static IPv4 Address

” pp. 66-67.

2. VMware vSphere Networking 7.0

“Configuring DNS and Routing for ESXi

” Section 3.3

pp. 31-33.

3. VMware KB 1005569

“DNS requirements for ESX/ESXi hosts and vCenter Server” (para. 1-3).

4. VMware vSphere Networking 7.0

“Host Name and Domain Settings

” pp. 34-35 (shows need for DNS servers and forward record).

To minimize downtime during a patching operation where virtual machines (VMs) cannot be migrated, a combination of two features is most effective. First, Quick Boot significantly reduces the ESXi host's reboot time by bypassing the lengthy hardware initialization (POST). This directly shortens the host's maintenance window. Second, since the VMs must be taken offline on the host, setting the VM power state to suspend to memory is the fastest method. This action saves the VM's running state to RAM and allows for a near-instantaneous resumption after the host is back online, minimizing the VM's specific downtime. vSphere Lifecycle Manager allows for configuring both of these settings for remediation tasks.

A. Distributed Power Management (DPM) is for power conservation, not for reducing patching downtime. Suspending to disk is significantly slower than suspending to memory, which increases downtime.

B. While Quick Boot correctly reduces host reboot time, suspending VMs to disk is a slower process than suspending to memory, thus not providing the maximum possible downtime reduction.

C. vSphere High Availability (HA) admission control ensures failover capacity and is unrelated to the speed of a planned patching operation. It does not reduce remediation downtime.

1. VMware vSphere 8.0 Documentation

Managing Host and Cluster Lifecycle

"Remediation Settings for vSphere Lifecycle Manager Baselines"

Section: "VM Power State". This section explicitly states: "You can configure vSphere Lifecycle Manager to change the power state of the virtual machines that run on the hosts that are remediated... Suspend to memory. The virtual machine is suspended and its memory is preserved." This confirms the VM handling part of the answer.

2. VMware vSphere 8.0 Documentation

vSphere Upgrade

"Using vSphere Lifecycle Manager and vSphere Quick Boot". This document states

"When you remediate a cluster

you can use the Quick Boot feature to reduce the time required for the ESXi host remediation. When an ESXi host reboots

it can skip the hardware initialization." This confirms the host handling part of the answer.

3. VMware vSphere 8.0 Documentation

vSphere Virtual Machine Administration

"Suspend and Resume Virtual Machines". This guide explains the suspend operation: "When you suspend a virtual machine

you store its current state... Resuming a suspended virtual machine is faster than powering on a powered off virtual machine." It also differentiates between suspend to memory (standby) and suspend to disk (hibernate)

with the former being faster for resumption on the same host.