By generating graphs, you can display performance and usage statistics for up.time Elements. Generating graphs helps you diagnose problems through root-cause analysis, as well as review the overall health and performance of monitored Elements. With vSync, you can generate graphs for VMware vSphere components that are being monitored by up.time, allowing you to diagnose and review all components of your infrastructure—whether virtual assets or physical ones—from the same view.
When viewing the Graphing tab for any VMware vSphere component, you will see different graphing options depending on the type of VMware vSphere object, or in the case of VMs, the operating system that is running.
You can view the status of your VMware vCenter servers, ESX servers, and VMs using Quick Snapshots. The Quick Snapshot summarizes both the recent and current performance of key hardware and process information for a VMware vSphere component that exists in up.time as an Element, and can help administrators identify potential issues.
If there are not 24 hours’ worth of data available, up.time will use data from as far back as possible to generate charts. |
The Quick Snapshot is typically used as a preliminary step toward root cause analysis. When you first acknowledge an issue by clicking an Element name on either Global Scan, or the My Alerts section of My Portal, you are shown the Quick Snapshot for that Element. From here, you can work with the information provided in the charts and tables and begin further investigation:
The following information is displayed in a VMware vCenter server Quick Snapshot:
Datacenter Summary | ||
datacenters that are being monitored are listed in alphabetical order, along with resource information for the datacenter as a whole | ||
CPU Capacity Trend |
| |
Memory Capacity Trend |
| |
Total Active CPU | the total CPU cycles, in GHz, that are available, whether they are currently being used | |
Total Active Memory | the total available memory, in GB, that is available, whether it is currently in use | |
Running VMs and Hosts Count |
| |
Active Outages |
| |
Top Clusters / Top ESX Servers | ||
the top five clusters and ESX servers are respectively listed in order of current CPU usage | ||
CPU Trend 24h | the CPU usage trend of the cluster or ESX server over the last 24 hours, expressed as a percentage of total available CPU cycles
clicking opens a pop-up displaying a CPU Workload graph showing actual CPU usage over the last 24 hours | |
Current % | the current percentage of total available CPU cycles being consumed by the cluster or ESX server | |
the top five clusters and ESX servers are respectively listed in order of memory used | ||
Memory Trend 24h | the memory usage trend of the cluster or ESX server over the last 24 hours, expressed as a percentage of total available memory
clicking opens a pop-up displaying a Memory Workload graph showing actual memory usage over the last 24 hours | |
Current GB | the current percentage of total available memory currently being used by the cluster or ESX server | |
Top Resource Pools | ||
the top five resource pools are listed in order of current CPU usage | ||
CPU Trend 24h | the CPU usage trend of the resource pool over the last 24 hours, expressed in raw GHz
clicking opens a pop-up displaying a CPU Workload graph showing actual CPU usage over the last 24 hours | |
Current GHz | the amount of CPU cycles, in raw GHz, currently consumed by the resource pool | |
the top five resource pools are listed in order of memory used | ||
Memory Trend 24h | the memory usage trend of the resource pool over the last 24 hours, expressed in raw GBs
clicking opens a pop-up displaying a Memory Workload graph showing actual memory usage over the last 24 hours | |
Current GB | the amount of total memory, in raw GB, currently being used by the resource pool |
The following information is displayed in an ESX server or cluster Quick Snapshot:
CPU Usage | the following is shown for the last 24 hours, where the mouse-over segments are in 10-minute intervals:
| |
VM state | the following is shown for the last 24 hours, where the mouse-over segments are in 10-minute intervals:
| |
Memory Usage | the following is shown for the last 24 hours, where the mouse-over segments are in 10-minute intervals:
| |
Swap Usage vs. Swap Rate | the following is shown for the last 24 hours, where the mouse-over segments are in 10-minute intervals:
| |
Disk I/O Rate | the following is shown for the last 24 hours, where the mouse-over segments are in 10-minute intervals:
| |
Network I/O Rate | the following is shown for the last 24 hours, where the mouse-over segments are in 10-minute intervals:
| |
Top VMs by CPU |
| |
Top VMs by Memory |
| |
Top VMs by Disk I/O |
| |
Top VMs by Network I/O |
|
The following information is displayed in a virtual machine Quick Snapshot:
CPU Usage | the following is shown for the last 24 hours, where the mouse-over segments are in 10-minute intervals:
| ||
% Wait and % Ready Time | the following is shown for the last 24 hours, where the mouse-over segments are in 10-minute intervals:
| ||
Memory Usage | the following is shown for the last 24 hours, where the mouse-over segments are in 10-minute intervals:
| ||
Swap Usage vs. Swap Rate | the following is shown for the last 24 hours, where the mouse-over segments are in 10-minute intervals:
| ||
Disk I/O Rate | the following is shown for the last 24 hours, where the mouse-over segments are in 10-minute intervals:
| ||
Network I/O Rate | the following is shown for the last 24 hours, where the mouse-over segments are in 10-minute intervals:
| ||
Top 10 Processes | note that this process list is only available if the VM Element’s metrics are being reported via WMI or the up.time Agent
|
To display the Quick Snapshot page for any VMware vSphere component, do the following:
Note that when you are viewing an Element’s profile, you can always access its Quick Snapshot by clicking the Graphing tab, then clicking Quick Snapshot in the tree panel.
up.time uses the following graphs to chart the performance of one or more CPUs on a system:
CPU Workload graphs help you gauge the demand being placed on your computing resources, and understand specifically from where it is coming. For example, for a VMware vCenter server, you can find out which ESX servers or clusters are consuming the most CPU cycles, or for an ESX server, which VMs are creating the largest workload.
For CPU Workload graphs for a VMware vCenter server, the amount of MHz used can be generated for the following Element types:
For CPU Workload graphs for an ESX server, the amount of MHz used can be generated for the following Element types:
To generate a CPU Workload graph, do the following:
Go to the Element’s Quick Snapshot page.
For example, in the My Infrastructure panel, find the VMware vCenter server or ESX server whose workload you want to graph, click its corresponding gear icon, then click Graph Performance .
The CPU Usage graph shows how CPU resources are managed and used across all instances on an ESX server, or an individual VM.
The following metrics are displayed in a CPU Usage graph:
Reservation | the minimum amount of CPU resources reserved for the VM, or all VMs running on an ESX host | |
Entitlement | the amount of CPU resources allocated to a VM, or all VMs running on an ESX host, on the assumption that all VMs on a host are completely busy, and load is perfectly balanced across hosts | |
Usage MHz | the amount of CPU used, in MHz, by the VM, or all powered on VMs running on the ESX host | |
Usage % | the amount of CPU resources, as a percentage of total available CPU, used by the cluster, ESX host, or VM | |
Usage % (agent) | the amount of CPU resources, as a percentage of total available CPU, used by a VM that is reporting detailed metrics via WMI or the up.time agent |
To generate a CPU Usage graph, do the following:
The Multi-CPU Usage graph charts the performance statistics for ESX hosts or VMs with more than one CPU. These statistics indicate whether or not a system is effectively balancing tasks between CPUs, or if processes are being forced off CPUs in certain circumstances. You can also use this graph to determine whether or not there are too many system interrupts that are using a CPU or that are overloading a CPU.
The following metrics are displayed in a Multi-CPU Usage graph:
ESX Server | ||
Usage MHz | usage of total CPU resources by physical cores, as a percentage, on the ESX host | |
Virtual Machine | ||
Usage MHz | the amount of CPU usage, in MHz, by CPU, on the VM | |
% System Time | the amount, as a percentage, spent on system processes on each vCPU in the VM | |
% Wait Time | the amount, as a percentage, vCPUs on the VM spent in wait state | |
% Used | the amount, as a percentage, of used vCPU time | |
Virtual Machine with WMI- or Agent-Based Metrics | ||
% Total | total amount of user, privileged, and interrupt time, by vCPU | |
% Usr | the amount of time, as a percentage, of user processes, by vCPU | |
% Sys | the amount of time, as a percentage, of system process use, by vCPU | |
% Wait | the amount of time, as a percentage, of wait time use | |
Interrupts | number of CPU interrupts |
For the % Wait metric, it is possible that you will see values that exceed 100%. The underlying data used for the CPU graphs are migrated from VMware vSphere via vSync; VMware conventions include percent-based metrics that can be greater than 100%. For example, refer to the VMware Technical Note, Performance Counters, at http://www.vmware.com/files/pdf/technote_PerformanceCounters.pdf. |
To generate a multi-CPU usage graph, do the following:
CPU wait time is the amount of time a VM is given scheduled time, but there is nothing to process, resulting in an idle CPU.
CPU ready time is the amount of time that a VM is ready for processing, but could not get scheduled to run on the physical CPU.
The Wait and Ready Time graph helps you determine if a guest is waiting too often on a host, or a host is waiting too often on a guest.
The following metrics are displayed in a Wait and Read Time graph:
% Wait | the amount of time during the interval, as a percentage, that the VM or all VMs on an ESX host, resource pool or vApp had scheduled CPU time, but gave nothing to process | |
% Ready | the amount of time during the interval, as a percentage, that the VM or all VMs on an ESX host, resource pool or vApp were ready to process, but were not scheduled CPU time by the host |
For these metrics, it is possible to be presented with values that exceed 100%. The underlying data used in these graphs are migrated from VMware vSphere via vSync; VMware conventions include percent-based metrics that can be greater than 100%. For example, refer to the VMware Technical Note, Performance Counters, at http://www.vmware.com/files/pdf/technote_PerformanceCounters.pdf. |
To generate a percent-wait or percent-ready graph, do the following:
To generate a percent-wait or percent-ready graph for a VM that receives metrics via WMI or the up.time agent, do the following:
up.time uses the following graphs to chart memory usage for a system:
Memory Workload graphs help you gauge the demand being placed on the memory allocated to your physical and virtual, and understand specifically from where it is coming. For example, for a VMware vCenter server, you can find out which ESX servers or clusters have been using the most memory, or for an ESX server, which VMs are the recipients of overcommitted granted memory.
The following metrics can be used to generate a Memory Workload graph:
VMware vCenter Server | ||
Consumed | the amount of memory, in MB, that is used by or reserved for a VM, or all VMs that are part of a resource pool or vApp, or the total physical memory used by the datacenter, cluster, or ESX host | |
Ballooned | the amount of guest physical memory being reclaimed through ballooning from a VM, or all VMs that are part of a resource pool or vApp, or the total memory balloon for all VMs in a datacenter, cluster, or ESX host | |
ESX Server | ||
Usage | the amount of memory used, as a percentage of total available memory, by all VMs on the ESX host, or in a resource pool or vApp | |
Active | the estimated amount of active memory in use, in KB, by VMs, or all VMs in a resource pool or vApp | |
Consumed | the amount of memory, in MB, that issued by or reserved for a VM, or all the VMs that are part of a resource pool or vApp | |
Granted | the amount of physical memory allocated to machine memory for a VM, or all the VMs that are part of a resource pool or vApp | |
Ballooned | the amount of guest physical memory being reclaimed through ballooning from a VM, or all VMs that are part of a resource pool or vApp |
To generate a Memory Workload graph, do the following:
The Memory Usage graph displays the amount of memory being used on an ESX server, or a VM.
The following metrics are displayed in a Memory Usage graph:
ESX Server Metrics | ||
Reservation | the minimum amount of memory reserved for VMs running on an ESX host | |
Consumed | the amount of memory, in MB, that is used by or reserved for VMs running on an ESX host | |
Active | the estimated amount of active memory in use, in MB, by VMs running on an ESX host | |
Granted | the amount of memory allocated to VMs running on an ESX host, on the assumption that all are completely busy, and load is perfectly balanced across hosts | |
VM metrics | ||
Reservation | the minimum amount of memory reserved for the VM | |
Entitlement | the amount of memory, in MB, allocated to a VM, on the assumption that all VMs on a host are completely busy, and load is perfectly balanced across hosts | |
Consumed | the amount of memory, in MB, that is used by or reserved for a VM | |
Active | the estimated amount of active memory in use, in MB, by the VMs | |
Granted | the amount of physical memory allocated to machine memory for a VM | |
Used MB (Agent) | the amount of memory used by a VM that is reporting detailed metrics via WMI or the up.time agent |
To generate a Memory Usage graph, do the following:
The Memory Profile graph displays trends in allocated memory for VMs on an ESX server. Use this graph to ensure VMware vSphere’s memory resource management techniques are working correctly.
The following metrics are displayed in a Memory Profile graph:
ESX Server Metrics | ||
Shared Common | the amount of machine memory that is shared by all powered on VMs on the ESX host | |
Swapped | the total amount of guest physical memory swapped out to swap files of all VMs running on the ESX host | |
Ballooned | the total memory balloon of all powered on VMs | |
Overhead | the total amount of machine memory used to run all VMs running on the ESX host | |
VM metrics | ||
Shared | the amount of guest physical memory shared with other VMs | |
Swapped | the amount of guest physical memory swapped out to the VMs swap file | |
Ballooned | the amount of guest physical memory being reclaimed through ballooning from a VM | |
Overhead | the amount of machine memory used to run the VM |
To generate a Memory Profile graph, do the following:
This graph indicates whether or not a VM guest is short of memory.
The following metrics are displayed in a Guest Paging graph:
Page In/sec | number of memory pages transferred from disk to RAM | |
Page Out/sec | number of memory pages transferred from RAM to disk | |
Page Frees/sec | number of memory pages removed from being swapped to and from RAM and secondary storage |
To generate a guest memory paging rate graph for a VM that receives metrics via WMI or from the up.time agent, do the following:
The Memory Swap graph charts the amount of memory held in swap files on ESX servers, as well as the rates at which data is swapping between memory and secondary storage.
The following metrics are displayed in a Memory Swap graph:
ESX Server Metrics | ||
Swapped | total guest physical memory, in MB, swapped out to swap files of VMs in resource pools, vApps, or on the ESX host | |
Swap Total Rate | the total swap in rate and swap out rate, in MB, for VMs in resource pools, vApps, or on the ESX host | |
VM Metrics | ||
Swap Used | the amount of guest physical memory, in MB, swapped out to the VM’s swap file | |
Swap In Rate | the rate at which memory, in MB, is swapped into active memory | |
Swap Out Rate | the rate at which memory, in MB, is being swapped out to disk | |
Swap Used MB (Agent) | the amount of guest physical memory, in MB, swapped out to the VM’s swap file, as reported via WMI or the up.time agent |
To generate a percent-wait or percent-ready graph, do the following:
To generate a Memory Swap graph for a VM that receives metrics via WMI or the up.time agent, do the following:
up.time uses the following graphs to report system process information for VMware vSphere-monitored VMs whose metrics are reported via WMI or with the up.time agent:
The Process Workload graph determines the demand that network and local services are putting on a VM whose metrics are reported via WMI or with the up.time agent. The graph charts an aggregate amount of performance information for a given user, group, or process.
The following metrics are displayed in a Process Workload graph:
% CPU | the percentage of the VM’s CPU time that is taken up by a user, group, or process | |
Total Memory Size |
| |
RSS Memory Size |
|
To generate a Process Workload graph for a VM that receives metrics via WMI or the up.time agent, do the following:
Detailed process information provides insight into how various user and system processes are consuming system resources.
The following information is displayed in a Detailed Process Information table:
Process | the name of the process, which is taken from its executed path name | |
PID | the number that identifies the process | |
PPID |
| |
UID |
| |
GID |
| |
Memory Used |
| |
RSS |
| |
CPU % |
| |
Mem % | the percentage of the memory used by the process | |
Runtime | the total runtime of the process | |
Children Runtime | the runtime of all child processes | |
Start Time | the time at which the process started, which can be used to determine its lifetime |
To list Detailed Process Information for a VM Element, do the following:
The Number of Processes graph displays the VM’s process activity with the following details:
Analyzing processes helps you determine whether or not there is enough CPU capacity for the processes that are being run on a system. If the size of the blocked or waiting queue is disproportionate to the running queue, then either the system does not have enough CPUs or is too I/O bound.
A blocked process signals a disk bottleneck. If the number of blocked processes approaches or exceeds the number of processes in the run queue, you should tune the disk subsystem. Whenever there are any blocked processes, all CPU idle time is treated as wait for I/O time. If database batch jobs are running on the system that is being monitored, there will always be some blocked processes. However, you can increase the throughput of batch jobs by removing disk bottlenecks.
The following WMI- or agent-based information is displayed in a Process Count table:
Running | the number of processes that are currently running on a system, as reported by the system kernel | |
Blocked | the number of processes that are unable to complete, usually due to I/O operation | |
Waiting | the number of processes awaiting execution | |
Total Processes | the total number of running, blocked, and waiting processes |
To generate a Number of Processes graph, do the following:
up.time uses the following graphs to chart network performance and usage:
Network Workload graphs help you gauge the demand being placed on the network, and understand specifically from where it is coming. For example, for a VMware vCenter server, you can find out which ESX servers or clusters are transmitting and receiving the most data, or for an ESX server, which VMs’ virtual NICs are the busiest.
For Network Workload graphs for a VMware vCenter server, the sum of KBps transmitted and received through NICs and vNICs can be generated for the following Element types:
For Network Workload graphs for an ESX server, the sum of KBps transmitted and received through virtual NICs can be generated for the following Element types:
To generate a Network Workload graph, do the following:
The I/O graph displays rates and total sums of data that are moving in and out of physical and virtual network interfaces over a specified time period. It can be used to find where I/O bottlenecks are occurring, and whether there have been any bursts in network traffic.
The following metrics are displayed in a Network I/O graph:
ESX Server Metrics | ||
Total Rate | the sum of data transmitted and data received, in KBps, through the physical NICs on the ESX host | |
Transmit Rate | the average rate, in KBps, at which data was transmitted through each physical NIC on the ESX host | |
Receive Rate | the average rate, in KBps, at which data was received through each physical NIC on the ESX host | |
VM Metrics | ||
Total Rate | the sum of data transmitted and data received, in KBps, through the vNICs on the VMs on the ESX host | |
Transmit Rate | the average rate, in KBps, at which data was transmitted through each vNIC on the VM | |
Receive Rate | the average rate, in KBps, at which data was received through each vNIC on the VM | |
Total Rate (Agent) | the sum of data transmitted and data received, in KBps, through the guest NICs on the VMs on the ESX host, as reported via WMI or the up.time agent | |
Send Rate (Agent) | the average rate, in KBps, at which data was transmitted through the guest NICs on the VMs on the ESX host, as reported via WMI or the up.time agent | |
Receive Rate (Agent) | the average rate, in KBps, at which data was received through the guest NICs on the VMs on the ESX host, as reported via WMI or the up.time agent |
To generate a Network I/O graph for an ESX server or VM, do the following:
The Network Errors graph displays the rate of errors with physical NICs on ESX servers, and vNICs on VMs.
The most common types of errors for physical connections include collisions in a hubbed environment or the presence of full-duplex handshake errors between a system and a switch. Additionally, the following communication line problems can cause network errors:
The following metrics are displayed in a Network Errors graph
ESX Server Metrics | ||
Total Dropped/min | the total number of dropped packets through the physical NICs on the ESX host, per minute, during the time period | |
Transmit Dropped/min | the number of packets outbound through the physical NICs on the ESX host that were dropped per minute during the time period | |
Receive Dropped/min | the number of packets inbound through the physical NICs on the ESX host that were dropped per minute during the time period | |
VM metrics | ||
Total Errors (Agent) | the sum of in errors and out errors through a guest NIC on the VMs on the ESX host | |
In Errors (Agent) | the number of packets received, but unable to be decoded due to a missing header or trailer | |
Out Errors (Agent) | the number of packets that were not sent, due to problems transmitting the packet or formatting the packet for transmission | |
Collisions (Agent) | the simultaneous presence of signals from two nodes on the network (e.g., from two nodes beginning to transmit over a network at the same time) | |
TCP Retransmits (Agent) | the number of TCP retransmits that occurred during the time period, due to lost or broken packets |
To generate a network error graph, do the following:
up.time uses the following graphs to chart disk details, performance, and usage:
Disk Workload graphs help you gauge the demand being placed on your physical or guest storage, and understand specifically from where it is coming. For example, for a VMware vCenter server, you can find out which ESX servers are experiencing the heaviest disk read/write activity, or for an ESX server, which VMs are writing the most to disk, prompting further investigation into VM read and write rates.
For Disk Workload graphs for a VMware vCenter server, the aggregated disk I/O rate, in KBps, can be generated for the following Element types:
For Disk Workload graphs for an ESX server, the aggregated disk I/O rate, in KBps, can be generated for the following Element types:
To generate a Disk Workload graph, do the following:
The Disk I/O charts the rates at which physical disks on ESX servers, and virtual disks on VMs are reading and writing data. VMs that are receiving metrics via WMI or the up.time agent report deeper metrics including wait times and data transfer speeds. These metrics can help you determine which disks are busiest.
The following metrics are displayed in a Disk I/O graph:
ESX server and VM Element Metrics | ||
Total RW Rate | the total read rate and write rate for virtual disks on VM, or LUNs on the ESX host | |
Read Rate | the rate, in KBps, at which data is read from each virtual disk on the VM, or each LUN on the ESX host | |
Write Rate | the rate, in KBps, at which data is written to each virtual disk on the VM, or each LUN on the ESX host | |
Total RW/min | the total number of read requests and write request from each virtual disk on the VM, or LUN on the ESX host | |
Read Requests/min | the number of times data was read from each virtual disk on the VM, or LUN on the ESX host | |
Write Requests/min | the number of times data was written to each virtual disk on the VM, or LUN on the ESX host | |
VM w/ agent Metrics on Guest Disks | ||
% Busy (Agent) | the percentage of guest disk capacity in use | |
Avg Queue Requests (Agent) | the average number of processes that are waiting to access the guest disk | |
Transfers/sec (Agent) | the total number of disk transfer requests processed per second | |
Blocks/sec (Agent) | the total number of data blocks written to and from the disk | |
Avg Service Time (Agent) | the average time, in milliseconds, required to perform a task | |
Avg Wait Time (Agent) | the average time, in milliseconds, that a transaction is waiting in a queue (note that the wait time is directly proportional to the length of the queue) |
To generate a Disk I/O graph, do the following:
To generate a Disk I/O graph for a VM that receives metrics via WMI or the up.time agent, do the following:
The Disk Errors graph charts the error rates on physical disks on ESX servers, or virtual disks on VMs. High error rates indicates performance issues with the underlying hardware.
The following metrics are displayed in a Disk Errors graph:
Bus Resets/min | the number of SCSI bus reset commands issued on the virtual disk on the VM, or host disk | |
Commands Aborted/min | the number of SCSI commands on the virtual disk on the VM, or host disk, that were aborted |
To generate a disk error rate graph, do the following:
The Disk Latency graph indicates the health and performance of physical storage on an ESX server.
The following metrics are displayed in a Disk Latency graph:
ESX Server Metrics | ||
Device Latency | the average amount of time, in milliseconds, required to complete a SCSI command from the physical device on the ESX host | |
Device Read Latency | the average amount of time, in milliseconds, required to complete reading from the physical device on the ESX host | |
Device Write Latency | the average amount of time, in milliseconds, required to complete writing to the physical device on the ESX host | |
Kernal Latency | the average amount of time, in milliseconds, VMKernel spent processing each SCSI command on the ESX host | |
Kernal Read Latency | the average amount of time, in milliseconds, VMKernel spent processing each SCSI read command on the ESX host | |
Kernal Write Latency | the average amount of time, in milliseconds, VMKernel spent processing each SCSI write command on the ESX host | |
Queue Latency | the average amount of time, in milliseconds, spent in the VMKernel queue, per SCSI command | |
Queue Read Latency | the average amount of time, in milliseconds, taken per SCSI read command | |
Queue Write Latency | the average amount of time, in milliseconds, taken per SCSI write command | |
Command Latency | the average amount of time, in milliseconds, to process a SCSI command issued by the guest OS to the VM | |
Command Read Latency | the average amount of time, in milliseconds, to process a read command issued from the guest OS to the VM | |
Command Write Latency | the average amount of time, in milliseconds, to process a write command issued fromt he guest OS to the VM |
To generate a percent-wait or percent-ready graph, do the following:
A Disk Storage Capacity graph charts the amount of total and used space, in gigabytes, on an Element’s disk. This includes VMware vCenter servers, ESX servers, and VMs. For VMs that are receiving metrics from the up.time agent, the capacity of the file systems are also available.
The current capacity and usage for each datastore is displayed, as well as the week-over-week change, and estimated time to fill. You can select a datastore to graph to see datastore usage trends over time.
The following metrics are displayed in a Disk Storage Capacity graph:
Total Capacity | the total amount of space available on the system or VM | |
Used | the amount of space current being used | |
Free | the amount of free space | |
Change Per Week | a positive or negative value indicating the amount of free space compared to one week ago | |
Time to Fill | based on the changes during the last week, the estimated amount of time before the disk is filled |
To generate a Disk Storage graph for a VMware vCenter Server, an ESX server, or a VM, do the following:
The Disk Storage Profile gives a breakdown of all datastores for an ESX server or VM. The current capacity and usage for each datastore is displayed. You can select a datastore to graph to see datastore usage trends over time.
The following information is displayed in a Storage Profile graph:
To generate a storage profile for an ESX server or VM, do the following:
up.time uses the following graphs to track and manage VMs:
The VMware VMotion tool enables you to move ESX instances from one server to another without any downtime or loss of data. For example, you might use VMotion to move an instance to newer and faster hardware, or to temporarily relocate the instance while performing a hardware upgrade.
The Instance Motion graph enables you to keep track of a moving VMware instance. For a given ESX instance, the graph charts which systems it has been running on over a given time range.
This graph can be generated when you are viewing a VMware vCenter server, ESX server, or a VM; the topological level at which you begin to configure the graph determines which instances are available to graph.
To generate an Instance Motion graph, do the following:
To assist virtualization initiatives that are meant to save power costs, or to gauge the efficiency of existing virtual datacenters, power usage by watts is available as a graphing metric.
The Power Consumption graph can tell you how much power your ESX hosts are consuming by datacenter, cluster, or individual server. Additionally, you can graph the power usage of individual VMs.
You can graph power usage levels at the VMware vCenter level in order to assess current load distribution, or verify VMware’s automated distributive resource balancing is functioning.
To generate a power consumption graph for a VMware vCenter server, do the following:
To generate a power consumption graph for an ESX server, do the following:
Power States graphs allow you to graph VM activity on an ESX host, or ESX activity on a VMware vCenter server.
The power state graphs help you manage both available computing resources within your VMware vSphere clusters and datacenters, as well as power consumption in your physical datacenters.
The following states are displayed in a Power States graph:
vCenter Server Metrics | ||
VMs Powered On | the virtual machine is powered on | |
ESX Powered On | the host is powered on | |
ESX Powered Off | the host was powered off by an administrator through the VMware vSphere Client | |
ESX Unknown | as is the case in the VMware vSphere Client, a host that is in an unknown state is assumed to have been powered off by an administrator | |
ESX In Maintenance | the host was put in maintenance mode by an administrator | |
ESX In Standby | the host was put in standby mode either explicitly by an administrator, or automatically by vSphere Distributed Power Management (DPM) | |
ESX Server Metrics | ||
VMs Powered On | the virtual machine is powered on | |
VMs Powered Off | the virtual machine is powered off | |
VMs Suspended | the virtual machine is not running, but a snapshot of its running applications and processes is retained. |
To generate a Power States graph, do the following:
To generate a power status graph for an ESX server’s VMs, do the following: