Domain 5 of the VCP-DCV exam — 'Monitor and Manage vSphere Performance and Capacity' — is where you learn how to keep a virtual datacenter healthy and prevent surprises. vSphere Monitoring and Alerting gives you the tools to watch your virtual machines and hosts constantly, so you can spot problems before they crash your applications and know when you need to add more resources.
Jump to a section
A simple way to picture vSphere Monitoring and Alerting
A vending machine route driver is responsible for keeping a network of machines stocked, functioning, and profitable. Every machine has a glass front, a payment system, a cooling unit, and a set of coils that dispense products. The driver visits each location regularly, but cannot stand in front of every machine 24 hours a day. Instead, the driver relies on a central dashboard that shows, in real time, the number of sodas left in each slot, the temperature inside the machine, the cash box level, and any mechanical errors like a jammed coil. If a machine reports that the cooling unit has failed while the driver is three towns away, the driver receives an alarm on their phone and knows which machine to prioritise before the chocolate melts. If the dashboard shows that a particular machine always runs low on crisps by Wednesday, the driver adjusts the restocking schedule rather than waiting for the machine to be completely empty. The driver also looks at historical reports: last month’s sales per machine, which products sold best, and how often each machine needed a service call. This allows the driver to plan preventive maintenance, order the right amount of stock, and ensure every location remains profitable. The vending machines themselves collect and send their data automatically; the driver does not need to phone each location to ask how many drinks are left. The central dashboard, the automated alerts, and the historical reports together form the driver’s complete monitoring and alerting system, ensuring that no machine stays broken or empty for long.
In the VMware world, the vCenter Server plays the role of the central dashboard. Each ESXi host (the physical server) and each virtual machine (the guest operating system) is like a vending machine that constantly reports its health, resource usage, and performance. vCenter collects all that data, and the vSphere administrator uses alarms, performance charts, and capacity reports to keep the virtual environment running smoothly and to plan for future growth, just as the driver uses machine data to keep the route profitable and efficient.
vSphere Monitoring and Alerting is the system that watches the health, performance, and resource usage of everything in your virtual environment: the physical servers (ESXi hosts), the virtual machines (VMs), the storage that holds their files, and the network they use to talk to each other. Without this system, you would be flying blind, only discovering a problem when users call to say an application is slow or a VM has shut down.
Think of your vSphere environment as a block of flats. Each flat is a virtual machine. The building itself (the ESXi host) provides electricity, water, and waste disposal (CPU, memory, disk I/O, network bandwidth). The building manager (vCenter Server) has a control panel that shows how much electricity each flat is using, whether any flat has a burst pipe, and how full the shared garbage bin is. Monitoring is the process of looking at that control panel in real time and recording readings over time. Alerting is the system that automatically sends a message (an alarm) when certain conditions are met — for example, if a flat’s electricity usage exceeds 90% of its allowance, the manager gets a red light and a text message.
The core components are:
ESXi hosts: The physical servers that run the hypervisor — the thin layer of software that creates and manages virtual machines. Each host has its own CPU, memory, network interfaces, and storage connections.
Virtual machines (VMs): A software-based computer that runs an operating system and applications, sharing the host’s physical resources.
vCenter Server: The central management platform that ties together multiple ESXi hosts, allowing you to see all VMs, apply settings, and configure alarms across the entire environment.
Performance charts: Graphs and tables inside vCenter that show resource usage over time — CPU load, memory consumption, disk read/write rates, and network throughput.
Alarms: Rules you define that trigger a specific action (like send an email, run a script, or change a VM’s power state) when a metric crosses a threshold.
vRealize Operations (now part of Aria Operations): An advanced, optional tool that goes beyond basic monitoring to provide predictive analytics, capacity planning, and automated remediation.
How it all works together: Every ESXi host collects performance data from its own hardware and from every VM running on it. This data is sent to vCenter Server, which stores it in a database (usually Microsoft SQL Server or PostgreSQL). vCenter Server provides built-in charts that display this data, and you can customise them to show exactly what you need. You can set alarms at the vCenter level, the host level, or the VM level. For example, you might configure an alarm that triggers when a VM’s CPU usage stays above 90% for five minutes, sending an email to the IT team. The alarm can also automatically increase the VM’s CPU entitlement if you use vSphere DRS (Distributed Resource Scheduler) — a feature that balances workloads across hosts.
Why this system exists: Before virtualisation, each physical server ran one operating system. If a server ran out of memory, you physically added more RAM and rebooted. Administrators relied on simple tools like Windows Task Manager or Linux ‘top’ command, and they watched for crashes. There was no central dashboard for hundreds of servers. vSphere Monitoring and Alerting solves the problem of scale: when you have hundreds or thousands of VMs, you need automated, centralised, and intelligent monitoring. Without it, you could miss a VM that is silently using 100% of its CPU for hours, degrading performance for users — or you might buy new hardware when the existing hosts are only 30% utilised.
What it replaces: Traditional monitoring required logging into each physical server individually, running scripts, or using separate hardware-based monitoring appliances. vSphere provides a single pane of glass. It replaces manual checking with automated alarms, and reactive troubleshooting with proactive capacity planning. You no longer wait for a user complaint; the alarm tells you there is a problem before anyone notices.
Select the object to monitor
Decide whether you want to monitor an entire datacenter, a cluster of ESXi hosts, a specific host, a resource pool, a single virtual machine, or a datastore. In vCenter, you navigate to the object in the inventory tree. The object you select determines which metrics are available. For example, a datastore object has metrics for disk space usage and I/O latency, but not CPU usage. Choosing the right object ensures your alarm is triggered by relevant data.
Define the alarm condition
Right-click the object, go to 'Alarms' -> 'New Alarm Definition'. Give it a name and description. Then choose a metric from a drop-down list (e.g., 'CPU Usage (%)' for a host, or 'Datastore Disk Usage (%)' for a datastore). Set the condition type: 'is above', 'is below', 'is equal to', or 'changes from'. For most resource alarms, 'is above' is common. Set the warning threshold (e.g., 75%) and the alert threshold (e.g., 90%). You can also set a duration — for how long the condition must persist before the alarm triggers (e.g., 5 minutes) to avoid false alarms from short spikes.
Configure alarm actions
After setting the condition, click 'Next' to add actions. You can add multiple actions per alarm. Common actions include: 'Send a notification email' (requires SMTP configuration), 'Send an SNMP trap', 'Run a command' (a script on vCenter Server, useful for automated remediation), and 'Change the power state of a VM' (e.g., power off a VM that is unresponsive). Each action can be assigned a specific severity (Warning or Alert). For example, when CPU usage hits Warning level (75%), send an email to the team. When it reaches Alert level (90%), also run a script that migrates VMs to another host.
Set alarm frequency and re-alarm options
You can configure how often the alarm re-triggers if the condition persists. In the alarm definition, set the 'Re-alarm cycle' — this is the time interval after which the alarm fires again if the condition has not cleared. For instance, set it to 5 minutes so you get a reminder every 5 minutes until the issue is resolved. You can also choose whether to enable the alarm to trigger on 'Multiple events' or only once. This step prevents you from being flooded with notifications.
Save, test, and monitor
Click 'Finish' to save the alarm. To test it, manually create a condition (e.g., run a CPU stress tool inside a VM) or use a test script. Monitor the 'Alarms' pane in vCenter to see if the alarm triggers as expected — you should see a yellow triangle for Warning or a red circle for Alert. If the alarm is not triggering, check your thresholds, the duration, and whether the object is actually reporting data. Over time, review the alarm’s effectiveness: adjust thresholds if false alarms occur frequently, or lower thresholds if you are missing real problems.
Consider a medium-sized company, ‘QuickShip Logistics’, which runs a virtualised datacenter with 20 ESXi hosts and 400 VMs. The company’s core application is a package tracking system used by 500 employees and accessed online by thousands of customers. The IT team of three people must ensure the system is available 24/7.
Monday morning, one of the administrators, Priya, opens vCenter Server. She checks the ‘Alarms’ view and sees a yellow triangle next to one ESXi host: ‘Host CPU usage is above 85%’. This is a warning alarm she configured weeks ago. She clicks the alarm to see the details: the host has 12 VMs, and two of them — both running a data analytics job — are using the most CPU. Priya checks the performance charts for those two VMs over the last hour. The charts show that CPU usage spiked to 95% and stayed there. She opens the ‘Resource Allocation’ tab for each VM and sees that they are configured with 4 vCPUs (virtual CPUs) each. The analytics job, which usually runs for one hour, is now taking two hours because the host is overloaded.
What does Priya do?
First, she uses vSphere’s built-in ‘Performance Charts’ to compare the CPU usage of all VMs on that host to understand if the problem is isolated or widespread. She sees that the analytics VMs are the culprits. Next, she checks the host’s memory usage — it is fine. She checks storage latency — also fine. The monitor tells her the problem is specifically CPU capacity.
Priya has several options:
Option 1: Manually migrate one of the analytics VMs to another host using vMotion, a feature that moves a running VM without downtime. This spreads the load.
Option 2: Increase the CPU priority of the analytics VMs using Resource Pools, but this is a temporary fix.
Option 3: Use vSphere DRS to automatically balance the VMs across all hosts. DRS is already enabled, but the analytics VMs were placed on the same host due to affinity rules (rules that keep VMs together for performance). Priya removes the affinity rule temporarily.
Option 4: Add more CPU capacity by upgrading the host or moving the analytics job to a different time of day.
After moving one VM to a different host, the alarm on the original host clears itself because CPU usage drops below the threshold. Priya then looks at the Capacity Planning tab in vCenter (or uses Aria Operations) to see if the company’s overall host cluster is approaching its maximum capacity. The report shows that cluster CPU utilisation is currently 60%, but the analytics job is growing 20% each month. At this rate, the cluster will hit 90% utilisation in four months. Priya escalates the issue to her manager, recommending the purchase of two additional hosts.
Later that week, the company’s database server VM experiences high disk latency. An alarm triggers because ‘average disk write latency’ exceeds 20 milliseconds. Priya investigates: the VM is on a shared storage array that also serves three other VMs performing backups. She uses the vCenter performance charts to confirm that the storage array’s queue depth (the number of I/O operations waiting) is high. The solution: she schedules backups to run at a different time and checks whether the VM’s virtual disk is thin-provisioned (over-allocated) or thick-provisioned. She decides to move the database VM to a faster, dedicated storage tier using Storage vMotion, which moves the VM’s files without downtime.
Throughout this scenario, Priya relies on alarms to tell her about problems immediately, performance charts to diagnose root causes, and capacity reports to plan ahead. Without these tools, she would only learn about the database latency from an angry user call, and she would have no data to prove that the backup schedules needed to change.
The VCP-DCV exam tests vSphere Monitoring and Alerting primarily through multiple-choice questions, drag-and-drop ordering tasks, and scenario-based items. You will not be asked to configure an actual alarm in a lab during the exam, but you must know the terminology, the default thresholds, and the steps to create and modify alarms. The exam loves to throw traps where two options are very close, and only one is correct because of a small detail like the alarm type (e.g., Host vs VM vs Datastore).
Here are the exact concepts the exam focuses on:
Alarm definitions versus alarm actions: An alarm definition is the rule (metric + condition + threshold). An alarm action is what happens when the rule is triggered (e.g., send a notification email, run a command, change the VM power state). The exam may ask you to identify which of these is NOT a valid alarm action.
Default alarms: vCenter comes with pre-configured alarms such as ‘Host CPU usage’ (warning at 75%, alert at 90%), ‘Virtual machine CPU usage’ (warning at 75%, alert at 90%), ‘Datastore usage on disk’ (warning at 75%, alert at 85%), and ‘Host memory usage’ (warning at 75%, alert at 95%). You must memorise these approximate thresholds — they love to test the exact percentage values for the default warning and alert levels.
Alarm severity: Red (Alert) or Yellow (Warning). The exam might ask which severity indicates that a condition is potentially problematic but not critical yet — answer: Warning (yellow).
Monitoring frequency: vCenter polls ESXi hosts every 20 seconds by default for real-time statistics. Historical data is rolled up into longer intervals (5-minute, 30-minute, 2-hour, 1-day averages) to save storage. The exam may ask about the default collection intervals.
Performance charts: You must know the difference between ‘Real-time’ (last hour) and ‘Historical’ charts (past day, week, month, year). Also, know that you can change the time range and the chart type (line chart, stacked area chart).
vCenter Server’s role: The exam might ask, ‘Which component is responsible for collecting performance data from ESXi hosts and storing it?’ Answer: vCenter Server (not the ESXi host itself, not the vSphere Web Client alone).
SNMP traps: vCenter can send alarms as SNMP (Simple Network Management Protocol) traps to external monitoring systems. The exam may ask what protocol is used for sending alerts from vCenter to a central network monitoring tool — answer: SNMP.
Email notifications: To send alarm emails, you must configure the SMTP (Simple Mail Transfer Protocol) server settings in vCenter. The exam may ask, ‘What service must be configured before vCenter can send alarm email notifications?’ Answer: SMTP server.
Alarm silencing: The exam might test the concept of ‘alarm acknowledgement’ — you can acknowledge an alarm to indicate that someone is working on it, which stops further notifications for that condition until the alarm resets.
Common traps: One trap is confusing ‘Alarm’ with ‘Event’. An alarm is a rule that triggers when a condition is met. An event is a record of something happening (e.g., VM powered on, host added to cluster). The exam may list several items and ask which are alarms and which are events. Another trap: believing that modifying a default alarm’s threshold changes it for all objects at once — it does, but only if you edit the default alarm definition at the folder or datacenter level, not at a specific object level.
Key definitions to memorise: - vCenter Server: central management server. - ESXi host: the bare-metal hypervisor. - Alarm: a condition that, when triggered, performs an action. - SNMP trap: an event notification sent to a network management system. - SMTP: protocol used for email notifications. - vCenter Performance Charts: tool for viewing historical and real-time data. - vCenter Events: entries logged for actions that occur in the vSphere inventory.
vCenter Server is the central brain that collects, stores, and processes performance data from all ESXi hosts and virtual machines in your environment.
Default alarms in vCenter trigger a Warning at 75% and an Alert at 90% for most resource metrics like CPU, memory, and disk usage.
An alarm consists of a definition (what to monitor and at what threshold) and one or more actions (send email, run script, send SNMP trap).
Performance charts in vCenter provide both real-time data (last hour) and historical roll-ups (5-minute, 30-minute, 2-hour, 1-day averages).
You must configure an SMTP server in vCenter before alarm email notifications can be sent – there is no built-in mail server.
Alarm acknowledgement is a way to notify other administrators that someone is handling the issue, but it does not prevent re-alarms if the condition persists.
vSphere alarms can be configured at multiple levels: vCenter, datacenter, cluster, host, resource pool, virtual machine, and datastore.
SNMP traps are the standard way to integrate vCenter alarms with external network monitoring systems like Nagios, SolarWinds, or PRTG.
These come up on the exam all the time. Here's how to tell them apart.
Alarm (Definition)
A rule that monitors a specific metric against a threshold
Performs an action when the condition is met (e.g., send email)
Can be configured, disabled, or deleted by an administrator
Event (Log Entry)
A record that something happened in the environment
Does not trigger actions by itself; it is just a log
Cannot be configured; events are generated automatically by actions and changes
Real-Time Performance Chart
Shows data from the last hour with 20-second interval updates
Ideal for troubleshooting immediate issues
Data is not persisted beyond one hour unless manually saved
Historical Performance Chart
Shows data from past days, weeks, months using rolled-up averages
Used for capacity planning and trend analysis
Data is stored in vCenter database for long-term review
Warning Severity Alarm
Indicates a potential problem, displayed as a yellow triangle
Default thresholds are typically lower, e.g., CPU 75%
Action is usually notification only, no automatic remediation
Alert Severity Alarm
Indicates a critical problem, displayed as a red circle
Default thresholds are higher, e.g., CPU 90%
Action may include automatic remediation like powering off a VM
vCenter Server Alarm Action: Email
Requires SMTP server configuration in vCenter
Delivers a human-readable email to specified recipients
Email is sent as plain text or HTML with alarm details
vCenter Server Alarm Action: SNMP Trap
Does not require SMTP; sends a structured data packet to an SNMP manager
Designed for machine-to-machine integration with network monitoring tools
Trap data includes OIDs (Object Identifiers) and variable bindings
Mistake
Alarms are only useful for serious emergencies; you don’t need to set warning alarms for things like CPU usage reaching 75%.
Correct
Warning alarms at lower thresholds (like 75% CPU) allow you to address a trend before it becomes a crisis, giving you time to migrate VMs or order hardware.
Beginners think alarms are for disasters only, but in production environments, warning-level alarms are crucial for proactive management and capacity planning.
Mistake
If I set an alarm on a VM, it will automatically monitor all metrics for that VM, like memory, disk, and network all at once.
Correct
Each alarm monitors a single metric against a specific condition (e.g., CPU usage > 80%). You must create separate alarms for different metrics if you want to watch multiple conditions.
It is natural to assume a single switch would cover everything, but vSphere alarms are granular and must be defined per metric.
Mistake
vCenter Server sends alarm emails directly to the admin’s email without any extra configuration.
Correct
You must configure an SMTP server (like an on-premises mail relay or a cloud email service) in vCenter Server settings before any email notifications can be sent.
vCenter itself does not have a built-in email server; it relies on an external SMTP server to deliver messages, which beginners often overlook.
Mistake
After an alarm triggers and you acknowledge it, you will not see the alarm again until the problem happens again from scratch.
Correct
Acknowledging an alarm says someone is working on it, but the alarm will reappear if the condition persists after the configured re-alarm cycle (e.g., every 5 minutes) or if the condition clears and then triggers again.
People think acknowledge = dismiss permanently, but it is just a temporary confirmation to stop repeated notifications while the issue is ongoing.
Mistake
Performance charts show only the last 24 hours of data for every VM by default.
Correct
By default, vCenter stores real-time data for the last hour, and then rolls up data into longer intervals (5-minute averages for 1 day, 30-minute averages for 1 week, etc.). The default view is real-time unless you change the time range.
Beginners assume ‘historical’ means always available for any period, but vCenter archive retention is based on time intervals and storage limits.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
An alarm is a rule that monitors a metric and performs an action when a condition is met. An event is a record that something happened, like a VM being powered on or a host disconnecting. Alarms are proactive; events are historical logs.
You must configure the SMTP server settings in vCenter Server under 'Administration' -> 'Solutions' -> 'vCenter Server Settings' -> 'Mail'. After that, when you create or edit an alarm, you can add an email notification action.
For a host or virtual machine, the default warning threshold is 75% CPU usage, and the default alert threshold is 90%. These values are configurable.
Yes. Select the datastore object in vCenter, create a new alarm definition, and choose the metric 'Datastore disk usage (%).' Set the warning threshold (default 75%) and alert threshold (default 85%).
A warning alarm (yellow icon) indicates a condition that may become problematic, like CPU usage above 75%. An alert alarm (red icon) indicates a critical condition that requires immediate attention, like CPU usage above 90%.
In the vSphere Web Client, select the VM, go to the 'Monitor' tab, then 'Performance'. Change the time range from 'Real-time' to 'This Week' or 'This Month'. You can also customise the chart to show specific metrics like memory, disk, or network.
An SNMP trap is a message sent from vCenter to an external network monitoring system when an alarm triggers. It allows you to centralise alerts from many systems into one platform, like Nagios or SolarWinds, so all your IT alerts are in one place.
You've finished vSphere Monitoring and Alerting. Continue through the VCP-DCV study guide to build a complete picture of the exam.
Done with this chapter?