Working with vCenter

What Is a vApp?
In this section, you will learn about vApps.
You can use VMware vSphere as a platform for running multi-tier applications, in addition to
running virtual machines. These applications can be packaged to run directly on top of
vSphere. This format of packaging and managing
applications is called vApp.
The example on the screen depicts a simple CRM application and the infrastructure required to
host this application. This multi-tiered application can be represented in vSphere as vApp, a
single inventory item. vApp specifies and encapsulates all the components of a multi-tiered
application, as well as the operational policies and service levels associated with it. This gives
the application owner full control.

Format of vApps:
vApps are packaged as Open Virtual Machine Format or OVF files. This format enables
exchange of virtual appliances across products and platforms and offers several advantages.
The first advantage is that OVF files are compressed, which enables faster downloads.
Additionally, vCenter Server validates an OVF file before importing it and ensures that it is
compatible with the intended destination server. OVF files also provide for rich metadata. This
enables you to describe important characteristics such as the vApp anatomy, its relationship to
other virtual machines, and resource and availability requirements.

vApp Packages:
A vApp package includes one or more virtual machines running the applications included in the
multi-application service. Each application is already set up and configured to run on the

virtual hardware of the virtual machine. Pre-deploying applications in virtual machines

eliminates the complex setup that usually accompanies the deployment of multi-tier services.
It also gives you the flexibility to change physical resources without affecting the service.
A vApp package also includes an OVF descriptor, which provides general application
information, hardware requirements, deployment instructions, and policies that are enforced
during runtime.
The vApp metadata resides in the vCenter Server's database, so a vApp can be distributed
across multiple ESXi hosts. This information can be lost if the vCenter Server database is
cleared or if a standalone ESXi host that contains a vApp is removed from vCenter Server. You
should back up vApps to an OVF package to avoid losing any metadata.

Deploying vApps:
You can use vCenter Server to create, package, and publish a vApp. Alternatively, independent
software vendors can develop and package vApps and publish them to the Virtual Appliance
Marketplace for deployment in vSphere. After deployment, the vApp is fully integrated into
the management infrastructure, which is greatly simplified.
You will now see a demonstration on creating and configuring vApps.

Alarms Overview:
Alarms are notifications that are set on events or conditions for an object. For example, the
vCenter Server administrator can configure an alarm on disk usage percentage, to be notified
when the amount of disk space used by a datastore reaches a certain level. The administrator
can also set alarms that are triggered when a virtual machine is powered off, the amount of
configured RAM used by the virtual machine exceeds a set capacity, or a hosts CPU usage
reaches a certain percentage.
The vSphere administrator can set alarms on all managed objects in the inventory. When an
alarm is set on a parent entity, such as a cluster, all child entities inherit the alarm. Alarms
cannot be changed or overridden at the child level.
The AlarmManager is the service interface for creating, setting, and managing alarms.

Tiggers and Actions:

Alarms have a trigger and an action. A trigger is a set of conditions that must be met for an
alarm to register. An action is the operation that occurs in response to the trigger.
Triggers for the default alarms are defined, but the actions are not. The vCenter Server
administrator must manually configure the alarm actions, for example, sending an email
notification.
Triggers and actions answer three questions.
First, what is the threshold that your environment can tolerate?
Second, when should a notification
be sent?
And last, what action should be

taken in response to the alarm?

Alarm Trigger Types:

You can set alarms for objects such as virtual machines, hosts, clusters, datacenters,
datastores, networks, vNetwork Distributed Switches, distributed virtual port groups, and
vCenter Server.
Alarms have two types of triggers. They can be triggered by the condition or state of an object
or by events occurring on an object.
You will now learn more about these types of triggers.

State and Condition Triggers:

Condition triggers monitor metrics for a host, virtual machine, or datastore, whereas state
triggers monitor the current state of a host, virtual machine, or datastore. For a condition
trigger to issue a warning or an alert, each value set must be reached for a specified duration.
For example, you can configure a condition trigger so that a virtual machines CPU usage must
be above 75% for more than 10 minutes to generate a warning, and above 90% for more than
5 minutes to generate an alert. The 10 minute and 5 minute time conditions in this example
help distinguish an erratic condition from a true scenario. You set time requisites to ensure
that the metric conditions are valid and not caused by incidental spikes.
Triggered alarms reset when the triggering condition or state is no longer true. For example, if
you have an alarm defined to trigger a warning when host CPU usage is above 75%, the
condition will reset to normal when the value falls below 75% and the warning alarm will no
longer be triggered. The threshold condition is dependent on any tolerance values you set for
the threshold.

Event Triggers:
Events are the records of user actions or system actions that occur on objects in vCenter
Server or on a host. Event data includes details about the event, such as who generated it,
when it occurred, and what type of event it is.
An alarm triggered by an event might not reset to a normal state if vCenter Server does not
retrieve the event that identifies the normal condition. In such cases, reset the alarm manually
to return it to a normal state. In vSphere Client locate the triggered alarm in the Triggered
Alarms panel or on the Alarms tab for the object. Right-click the alarm and select Reset Alarm
to Green.
For example, say you have a subset of hosts in the same datacenter named with the identifying
prefix, QA_. To trigger an alarm when any of these hosts lose network connectivity, you must
create an alarm on the datacenter to monitor the event Lost Network Connectivity. The trigger
conditions can be Argument, which is host name, Operator, which is starts with, and Value,
which is QA_. When storage connectivity is lost on any hostname prefaced with the characters
QA_, the event triggers.

Alarm Actions:
After you have set the triggers for an alarm, you must assign an action. Alarm actions are
operations that occur in response to triggered alarms. VMware vCenter Server provides a list
of preconfigured actions that you can associate with an alarm. These actions are specific to the
object on which the vSphere administrator sets the alarm. For example, preconfigured alarm
actions for hosts include rebooting the host and putting the host in maintenance mode. Alarm
actions for virtual machines include powering on, powering off, and suspending the virtual
machine.
Although the actions are preconfigured, the vSphere administrator must manually set up
certain aspects of the action, such as setting the action to occur when a warning is triggered or
when an alert is triggered, and specifying whether to repeat the action. The green indicator
means a normal condition, yellow indicates a warning, and red indicates an alert status.
For every action, the vSphere administrator can specify one of three options for each color
transition: Empty, Once, or Repeat. Empty indicates no interest in the transition. Once
instructs vCenter Server to fire the action only one time, and Repeat instructs vCenter Server
to repeat the action until another color change occurs. The default time of action is five
minutes; the maximum is two days.

Acknowledging Triggered Alarms:

While a triggered alarm is being resolved, a vSphere administrator can explicitly acknowledge
the triggered alarm in any triggered alarm list. This notifies other vSphere administrators that
the triggered alarm is being addressed. Acknowledging a triggered alarm also suppresses the
alarm actions from occurring. The vSphere administrator can acknowledge one or more
triggered alarms at a time. The Acknowledged and Acknowledged By columns show when and
by whom the alarm was acknowledged.
This concludes the discussion on alarms and events. In the next section, you will learn about
performance charts and their utility in monitoring and troubleshooting performance in your
virtual environment.

Performance Charts:
Performance charts graphically represent statistical data for various devices and entities
managed by vCenter Server. They display data for a variety of metrics, including CPU, disk,
memory, and network usage.
VMware provides several preconfigured charts for datacenters, hosts, clusters, datastores,
resource pools, and virtual machines. Each metric for an inventory object is displayed on a
separate chart and is specific to that object. For example, the metrics for a host are different
from the metrics for a virtual machine.
vSphere administrators can view performance charts through the vSphere Client Performance
tab for the object selected in the inventory. Depending on the object selected, data can be
displayed in line graphs, stacked graphs, pie charts, or bar charts. Stacked graphs display data
on a single metric only, but can plot the data on that metric for multiple inventory objects. For
example, a line graph for a host CPU will show CPU usage for the host, as shown in the
screenshot here.

Using Performance Charts:

When using performance charts to find the root cause, it is recommended that the
performance engineer drills down from the most general report to the localized metrics. This
will enable performance engineers to find the root cause
issue faster and with greater accuracy.

Perform DLL in VMware Tools:

VMware Tools includes the Perfmon DLL that enables vSphere administrators to monitor key
host statistics from inside a virtual machine running a Windows operating system.
Perfmon is an SNMP-based performance monitoring tool for Windows operating systems. It
measures performance statistics at regular intervals and saves the statistics in a file.
Administrators can choose the time interval, file format, and statistics that are to be
monitored. The ability to choose which statistics to monitor is based on the available counters
for the selected object.
Installing the ESXi 5.0 version of VMware Tools automatically provides the Perfmon
performance counters, VM Processor and VM Memory. Using these counters, the application
administrator can collect accurate performance data for CPU utilization and compare it sideby-side with the virtual machines view of CPU utilization. This enables the application
administrator to better understand how resources are consumed in a virtualized environment.
Also, when a performance problem is identified, the vSphere administrator and the application
administrator can use a common tool such as Perfmon to isolate
the root cause.
Additionally, third-party developers can instrument their agents to access these counters using
Windows Management Instrumentation or WMI.

Resource Maps:
vSphere administrators use resource maps to monitor proper connectivity which is vital for
migration operations, such as VMware vSphere vMotion or vSphere Storage vMotion.
Resource maps are also useful to verify VMware vSphere High Availability, VMware Distributed
Resource Scheduler or DRS cluster memberships, and resource connectivity.
A resource map is a visual representation of the datacenters topology. It visually represents
the relationships between the virtual and physical resources available in a datacenter.
Preconfigured map views that are available are Virtual Machine Resources, which displays
virtual machinecentric relationships, Host Resources, which displays host-centric physical
relationships, and vMotion Resources, which displays potential hosts for vMotion migration.
Maps help vSphere administrators find information such as which clusters or hosts are most
densely populated, which networks are most critical, and which storage devices are being
utilized.
Please note that if you are accessing map views using the Maps button in the navigation bar,
all vCenter Server resources are displayed, as shown in the screenshot here. If you are using
the Maps tab of a selected inventory item, only items
relevant to that item are displayed. For virtual machine inventory items, the vMotion
Resources view is the only map view available on the Maps tab.