When you create an alarm, you must define a trigger that generates a warning or alerts for a specific criteria being met. Triggers can either be event triggers or condition and state triggers. With an event trigger, a specific event will have occurred for a vCenter Server object. This can include a host being found to be noncompliant with the host profile assigned to it or an account being created on the host. Condition and state triggers monitor the current condition and state of vCenter Server objects, such as hosts and virtual machines. Common examples of these triggers include the CPU usage for a host or the power state for a virtual machine.

When you’ve decided which level to create a new alarm at, the following process can be used to create a new alarm. This example creates an alarm that monitors for datastore overallocation. With the support in vSphere for Thin Provisioning, it is possible to allocate more disk space to virtual machine disk files than is actually available in the datastore, so it is important to monitor available space on your datastores. There is a predefined alarm that will monitor the actual space being used on the datastore, but the disk overallocation trigger will help you find data-stores that may experience future space constraints.

One of the improvements to alarms that was introduced in vSphere was the ability to create triggers based on events. This allows for the monitoring of a wide range of events for virtual machines, hosts, clusters, and other vCenter objects. Event triggers can be created on any event that is available within the vSphere application programming interface (API). The API reference for vSphere 4.1 can be found at the following link: http://www.vmware.com/support/developer/vc-sdk/visdk41pubs/ApiReference/index.html. The API Reference documentation does not include a specific list of event triggers, but the VMware Communities document “vSphere Alarm Triggers” found at http://communities.vmware.com/docs/DOC-12145 includes a number of PowerCLI scripts to generate a list of event triggers.

The first example will create an alarm that triggers should the host loose network connectivity.

With the proceeding example, no advanced conditions were set for the event trigger. The trigger of Lost Network Connectivity will either be true or false, so no further conditions need to be configured. The following example looks at the host’s power status. In this case, the trigger has a status of Normal, Warning, or Alert. When you’re examining the API documentation or the output of the PowerCLI scripts from the “vSphere Alarm Triggers” document, you’ll find that the Power status of a host is a condition of the Hardware Health Changed event trigger. To enable an alarm based on the power status of the host, you have to configure advanced conditions, as shown in this example.

In the previous section of this chapter, you learned how to create alarms with vCenter Server. You create and edit alarm definitions by selecting the Alarms tab and then choosing the Definitions view. To view triggered alarms, you select the Triggered Alarms view as shown in Figure 6.13. The Triggered Alarms view shows any warning or alerts that have been triggered for the vCenter object that you have selected or any child objects. The sample in Figure 6.13 has the vCenter Server object selected and it has three child objects with warnings or alerts that have been triggered.

Figure 6.13. Viewing triggered alarms with vCenter Server.

When you select any vCenter object that has a triggered alarm for itself or a child object, the vSphere client displays either a warning or alert icon in the top-right corner of the content pane along with the number of warnings or alerts. This is also shown in Figure 6.13. If you click on the icons, the vSphere client switches to the Triggered Alarms view for that object.

Once you have reviewed the triggered alarms for an object, there are a number of actions that you can take. These include acknowledging the alarm, resetting the alarm, changing the alert, and disabling alarms.

Alarms that have a type of Monitor for Specific Conditions or State have typically been set up to monitor resource usage such as host CPU usage or space consumed on a datastore. With these alarms, as long as the condition that triggered the alarm persists, the alarm remains displayed in the Triggered Alarms view. Only after the alarm condition is resolved is the alarm removed from the list of triggered alarms. For these alarms, you can select the Acknowledge Alarm option. If you right-click on the triggered alarm, you have the option Acknowledge Alarm. Once you have selected the option, the Acknowledged column shown in Figure 6.13 is populated with the time stamp showing when the alarm was acknowledged, and the Acknowledged By column shows the user who acknowledged the alarm. The alarm still appears in the Triggered Alarms view, but it is grayed out. Once the alarm condition no longer exists, the alarm is removed from the view.

The other alarm type is set up to Monitor for Specific Events Occurring on This Object. Examples of this type of alarm include a virtual machine being powered off or a host being noncom-pliant with its host profile. With this type of alarm, you can also select the Acknowledge Alarm option or you can select the option Reset Alarm to Green as shown in Figure 6.14. This option is useful if vCenter Server does not retrieve an event that indicates that the alarm condition has returned to normal conditions. To reset an alarm right-click on the triggered alarm and select Reset Alarm to Green. The alarm is no longer displayed in the Triggered Alarms view until the alert condition reoccurs.

Figure 6.14. Resetting a triggered alarm to green.

In some cases, you might find it appropriate to disable alarm actions. This is a different option than editing an alarm and clearing the Enable This Alarm option. When you disable alarm actions, this is done on a vCenter object. Alarms are still triggered for an object, but the actions associated with the alarms no longer run. When you choose to disable alarm actions for an object, all alarm actions are disabled. However, alarm actions for child objects continue to execute. To disable alarm actions, right-click on the object when connected to vCenter Server and select Alarm > Disable Alarm Actions. You can enable alarm actions by right-clicking on the object again and selecting Alarm > Enable Alarm Actions.

While it is a useful option to disable alarm actions for an object, you may want to do so only temporarily. You can find objects that have had alarm actions disabled by looking in the following places in the vSphere client:

Lastly, when managing your alarms, you may want to change an alert. After you create an alarm, you may find that you need to edit the trigger conditions to better match those that are true alarm conditions in your environment. To change an alarm, you select the Definitions view and then right-click on the alarm to select Edit Settings. If you see the View Settings option instead, the alarm has been defined on a parent object and should be edited at that level.

AlarmActionsEnabled property is equal to false.

get-cluster | get-view | where {$_.AlarmActionsEnabled -eq $False} | Select
   Name, AlarmActionsEnabled
get-vmhost | get-view | where {$_.AlarmActionsEnabled -eq $False} | Select
   Name, AlarmActionsEnabled
get-vm | get-view | where {$_.AlarmActionsEnabled -eq $False} | Select Name,
   AlarmActionsEnabled
get-folder | get-view | where {$_.AlarmActionsEnabled -eq $False} | Select
   Name, AlarmActionsEnabled
get-datacenter | get-view | where {$_.AlarmActionsEnabled -eq $False} |
   Select Name, AlarmActionsEnabled
get-datastore | get-view | where {$_.AlarmActionsEnabled -eq $False} | Select
   Name, AlarmActionsEnabled
Name                                AlarmActionsEnabled
____                                ___________________
esx01.mishchenko.net                              False
openfiler-2.3-x86_64                              False
BC                                                False
Toronto                                           False

$esx = Get-VMHost esx01.mishchenko.net | Get-View
    foreach($triggered in $esx.TriggeredAlarmState){
    $alarmDef = Get-View -Id $triggered.Alarm
    Write-Host $alarmDef.Info.Name
    }

The Overview layout is the default view when selecting a Performance tab for a vCenter object. It provides a high-level overview of the relevant performance metrics for the object you are viewing. A number of charts are shown at the same time, allowing you to do a side-by-side comparison of resource usage for your chosen vCenter object. Figure 6.15 displays the Space view for a datastore on an ESXi host. The two pie charts at the top of the Space view display the space utilization by file type and by the top-five space-consuming virtual machines. The Space view also includes a line chart that summarizes the space being used in the datastore. Most views contain a number of charts that extend beyond what the vSphere client can display, so in most views you need to use the scroll bars to view all the charts provided. Table 6.4 provides a summary of the available views for the vCenter objects for which an Overview performance layout is available. Each Overview layout provides at least one view and you can select the View drop-down menu to choose another view.

Figure 6.15. The Space view for a datastore on an ESXi host.

For some time-based line charts, you can select the range of data displayed. This is the case with the Space in GB chart shown in Figure 6.15. Depending on the object you are looking at, you can select a range of Realtime, 1 Day, 1 Week, 1 Month, 1 Year, or a custom period. The Realtime range displays the last hour of performance data that the host has generated.

With advanced performance charts, you can customize your charts with the metrics you want to examine more closely. There are a number of customization options you can choose and you can export the performance data to a Microsoft Office Excel Workbook or a number of image file formats.

Figure 6.16 displays the Advanced layout for a VMware ESXi host. In the top-left corner of the image, you can see that the Power performance metrics are being displayed and that the data is being shown in real time. The Chart Options link allows you to configure the data shown in the chart; you can select the performance metric group to display, the chart type to use, and the time period to display. To the right of the Chart Options link you can use the Switch To drop-down menu to select a performance metric group to display. The available performance metric groups displayed depend on the type of vCenter object that you have selected. A summary of those groups is available in Table 6.5. To the right of the Switch To menu are icons for printing the current chart, refreshing the chart data, saving the chart, and detaching the chart from the vSphere client. The option to detach the performance chart is helpful if you want to keep the performance chart open while you perform other tasks with the vSphere client. You can detach multiple performance charts for side-by-side comparisons. When you select to save a chart, you can save it as an image file or an Excel Workbook. When you save the chart as an Excel Workbook, the spreadsheet is populated with the data points that comprise the chart along with chart that is based on that data.

Figure 6.16. The Advanced performance layout for an ESXi host.

When you select a group of performance counters to view with the Switch To menu, a set of default counters is displayed for the chosen performance metric group. You click on the Chart Options link to change the counters that are displayed as well as the chart type and time period shown. To customize your performance chart, you can follow this process:

If you plan to use the same chart settings on a continual basis, you can save your settings. Once you have configured your chart settings, click Save Chart Settings. Enter a new chart name in the dialog box that appears and then click OK to save the chart. You can select your new custom chart in the Saved Chart Settings drop-down menu and optionally check Always Load These Settings at Startup to make your new chart the default for when you select the Advanced layout for that specific vCenter object again. Chart settings are saved on a per-vCenter-object basis, so if you save a custom chart for one ESXi host, it will not be available for your other hosts. To delete a custom chart view, click Chart Options for the vCenter object and then select Manage Chart Settings. Select the chart to remove and click Delete. The chart will no longer be available on the Switch To menu.

On a performance chart, you can save the chart data to an Excel file that contains the data for that specific chart. You can also export all performance counters to an Excel file with the following steps:

The export process creates an individual Excel file for each metric group and another Excel file that pulls each of those files into a single Excel workbook.

One of the challenges of monitoring virtual machine performance in a virtualized environment is that the virtual machines are sharing various resources without knowing it. On a physical server, the operating system (OS) is aware of the total amount of physical memory that the host has. That’s not the case for an OS running in a virtual machine. It is aware of how much memory has been allocated to it, but that memory could be physical memory allocated solely to that virtual machine, or physical memory shared with other virtual machines; or, if the host is running low on memory, the virtual machine’s inactive memory may have been swapped by ESXi to disk. Thus when you’re troubleshooting performance issues in a virtual machine, you cannot depend solely on the performance counters that the guest OS is reporting.

For Windows guests, VMware Tools includes virtual machine–specific performance counter libraries for the Windows Performance Monitor utility. With these performance counter libraries, you can accurately see virtual machine CPU and memory usage. To access these performance counters with Windows 2008 Server, use the following process:

If you consider the issue described previously with memory, when you use native memory performance counters, you can ascertain what the OS believes is happening with memory. If it is low on memory, you can determine that the OS is starting to page memory to disk. But you will not be able to see what the host is doing with memory. With the VMware performance counters, you can see whether the host is swapping the virtual machine’s memory to disk. You can also determine the share allocation for memory, if a limit exists and if the memory balloon driver is being used. Likewise, with the VMware CPU performance counters, you can determine things such as actual CPU usage, determine the time that the virtual machine was runnable but not scheduled to run, and whether a CPU limit exists.

vSphere 4.1 Memory Compression

Memory compression is a new feature in vSphere 4.1 used to further enhance vSphere’s ability to perform memory overcommitment and thus to increase the number of virtual machines running on a single host. With memory over-commitment, you can allocate more memory to virtual machines than exists on a host as there will typically be virtual machines that are not using the full allocation of memory granted to them.

With vSphere 4.0 and prior versions of ESXi and ESX, the following three methods were used to reclaim memory from virtual machines: sharing memory across virtual machines, using the memory balloon driver, and using swap files.

A typical workload running on VMware ESXi includes the same guest operating systems, the same applications, and common data. ESXi uses the transparent page sharing (TPS) technique to share memory between those virtual machines. ESXi runs a background TPS process to find and eliminate redundant copies of memory pages. With a fairly constant workload, ESXi can slowly increase the amount of free memory on the host, allowing you to run more virtual machines on that host.

Part of the installation of VMware Tools includes the driver vmmemctl, which enables the memory balloon driver. When a host is running low on physical memory, the memory balloon driver uses a proprietary ballooning technique that causes the guest operating system to determine that it is running low on memory. The guest OS then uses its own native memory management tools to determine which memory pages to reclaim and if necessary which memory pages to swap to its own memory swap file on its virtual disk.

If the vmmemctl driver is not responding or able to force the guest OS to free any additional memory, ESXi uses swap files to reclaim memory forcibly from virtual machines. For optimal performance, ESXi relies on the memory balloon driver to reclaim memory before it begins to use swap files.

With ESXi 4.1, compressed memory is a new level in the memory hierarchy existing between RAM and disk swap files. Memory compression is enabled by default, and if a host’s memory becomes overcommitted, ESXi uses compression before it uses swap files, as accessing compressed memory is much faster than accessing the same memory page that has been swapped to disk. When a memory page in a virtual machine must be swapped, ESXi first attempts to compress the page. If the page can be compressed to 2KB or smaller, it is stored in the virtual machine’s compression cache rather than being swapped to disk. Figure 6.19 shows the quantity of compressed memory per virtual machine for a host that is memory overcommitted.

Figure 6.19. Performance chart showing memory compression per virtual machine.

Memory compression is controlled by using the Advanced Settings dialog box in the vSphere client. There are a number of settings that will control the behavior of memory compression on the host. The setting Mem.MemZipEnable is used to enable or disable memory compression and by default is enabled with a value of 1. The setting Mem.MemZipMaxPct is used to configure the size of the compression cache for the virtual machines on the host. The default value is 10 percent. With that value, for a virtual machine with 1000MB of memory, ESXi uses up to 100MB of memory for a compression cache.

The Reports view on the Storage Views tab provides a number of helpful reports on storage information. If you select the Datastore inventory view and then look at a specific datastore, you can quickly ascertain which virtual machines are using the datastore, which hosts have access to the datastore, and the status of all paths to the storage LUN. Figure 6.20 shows a report for a specific datastore. By default, the report shows which virtual machines are using the datastore, which host the virtual machine is on, what the multipathing status is, how many virtual disks for the virtual machine are on that datastore, the total datastore space used, and how much snapshot space is used for the virtual machine.

Figure 6.20. A Storage Views report showing space usage by virtual machines.

For each vCenter object, there are a number of specific category report views that you can use. To change the report category, use the Show All < Category Name drop-down menu. Figure 6.20 has the Show All Virtual Machines category displayed, and depending on the vCenter object you have selected, you’ll have the choice of the following categories:

In certain report categories, you’ll note that some items are highlighted in blue. In the case of Figure 6.20, the virtual machines and host are highlighted in such a manner. If you click on one of those items, the vSphere client will take you to the Storage Views tab for that specific object. You can also change the columns that are displayed for a specific category. Right-click on the column headings in the Report view and you will be presented with a list of columns to show or hide. With the Show All Virtual Machines category, you can select to view Virtual Disk Space, Uncommitted Space, and other columns relevant to virtual machine storage usage.

If you find that too much data is shown in a certain category report, you can filter the results using the search field shown in Figure 6.20. Click the search field arrow and select the attributes to include in the search. Type in a keyword and press Enter to search the Report view. You can click the Clear link to remove your search filter.

If you want to work with the data in the Report view in another application, you can easily export the data. Right-click below the table data and select Export List menu option. On the Save As dialog bog, enter a filename for your export file, select an appropriate file format, and click OK to save the file.

Storage maps provide a visual representation of the relationships between the vCenter object that you select and the storage resources that it uses. The storage maps display only items relevant to the specific object and are object-centric. As with the Report view map, data is updated every 30 minutes but you can click the Update link shown in Figure 6.21 to refresh the data used to generate the map.

Figure 6.21. A storage map for a host showing connected datastores and virtual machines.

Figure 6.21 displays the storage map for a specific host. Using the Show options, the user has updated the display to show only the datastores available to the host and the virtual machines stored on those datastores. You can select any number of items in the Show area and then click Update Now to update the generated map.

In some cases, you may find the map so cluttered that you cannot properly view all the items. You can right-click on an item and select Hide Node to remove it from the map. To select multiple objects, press the Ctrl key while selecting the objects and then right-click to select Hide Node. To display any hidden objects, right-click on the map and select Show Hidden Nodes. For an alternative to hiding items, you can click one or more objects in the map to select them and then drag them to an empty space on the map.

You can export the map for use in other applications. Right-click on an empty space in the map and select Export Map. You can select among a number of image formats when saving the file. If you want to examine an object in the map more closely, you can right-click on an object to view a number of Switch To options on the context menu. In Figure 6.21, a datastore is selected and you can switch to the Configuration tab, Summary page, Storage Maps view, or one of the Storage Report views for the datastore.

To reduce the system footprint and eliminate the need for additional third-party agents, which can introduce instabilities and other problems, VMware has incorporated the standard CIM into ESXi and ESX. The CIM is an open standard that defines how managed elements in your information technology (IT) environment are represented as a set of common objects and the relationships among them. The CIM standard is defined and published by the Distributed Management Task Force (DMTF). Another DMTF standard used is the Web-Based Enterprise Management (WBEM), which defines a particular implementation of CIM, including protocols for discovering and accessing CIM implementations.

The CIM framework consists of CIM providers, which in this case are developed by VMware and its partners to enable management and monitoring of the hardware devices in your vSphere environment. As your hardware environment is represented using an open standard, any management tool that implements the CIM standard can manage your host. Management applications use protocols such as CIM Extensible Markup Language (CIM XML) and Web Services for Management (WSMAN) to monitor and manage the device information provided by the CIM providers. The ESXi CIM implementation consists of the components shown in Figure 6.22.

Figure 6.22. The ESXi CIM software architecture.

Providing data to the CIM providers are various components such as the drivers used to interact with your host’s hardware, the host’s Intelligent Platform Management Interface (IPMI), and the system management Basic Input/Output System (SMBIOS). The CIM providers are used to access the device drivers and the host’s hardware. VMware writes providers that implement monitoring of hardware components, the storage infrastructure, and virtualization specific resources. Hardware vendors can also provide CIM providers for their specific devices. In some cases, these provide an interface that can be used to configure hardware devices, such as changing an array on a storage controller. In other cases, these providers extend the information that is available to management applications. While the VMware provider supplies basic information about a host’s CPUs, the vendor provider includes CPU temperature and more detailed CPU model and version information. Vendor-supplied CIM providers will either be included on the installation media or added as described in the next section.

Managing the CIM providers is the CIM object manager (CIMOM). The CIMOM can also be referred to as a CIM broker. The CIMOM in ESXi implements the Common Manageability Programming Interface (CMPI) standard. The CMPI standard defines a common standard of interfacing between CIM providers and clients and the CIM broker. VMware ESXi uses the Small Footprint CIM Broker (SFCB), which is designed for environments with constrained resources.

The CIM client running in ESXi is Openwsman, which is an open source implementation of the Web Services Management specification. Openwsman communicates with the CIMOM via the CMPI standard. The Openwsman service in turn exposes CIM data to external CIM clients such as the vSphere client. Openwsman supports CIM connections over CIM XML, WSMAN, and the Service Location Protocol (SLP).

In Chapter 2, “Getting Started with a Quick Install,” the section “Adding CIM Support to the Generic ESXi Installable Image” discussed how hardware vendors have begun to release offline update packages that add CIM support to the VMware release ESXi installation image. These packages use the vSphere Installation Bundle (VIB) format and can be installed on your host to augment the CIM data that will be provided to the CIM clients in your management infrastructure. Without the vendor-supplied CIM providers, you may not be able to obtain detailed health data for your servers and other hardware components.

The following process demonstrates the installation of the Dell OpenManage offline bundle for ESXi:

When you have connected the vSphere client directly to an ESXi host, you can view the health status for the host on the Configuration tab. After you have selected Health Status, the vSphere client displays the status for all hardware components detected by CIM providers, as shown in Figure 6.23.

Figure 6.23. Viewing the Health Status page when directly connected to an ESXi host.

Components that are functioning normally display a status indicator of green. If a component is not functioning properly or is exceeding a performance threshold, the status indicator changes to yellow or red. A yellow indicator indicates degraded performance, whereas a red indicator means that a component has failed or has exceeded its highest threshold. If the status column for a component is blank, the CIM providers have not been able to determine the status.

The Reading column displays the current value for the sensors. In Figure 6.23, the Reading column displays the temperature of the motherboard in the ESXi host.

The data shown in the Health Status pages is refreshed automatically every few minutes. You can update the display manually by clicking the Refresh link. Some sensors display data that is cumulative over time. You can click the Reset link to clear the data for those sensors so that they begin to collect new data.

$VMHostName = "esx01.mishchenko.net"
$HostView = Get-VMHost -Name $VMHostName | Get-View
$HealthStatusSystem = Get-View $HostView.ConfigManager.HealthStatusSystem
$SystemHealthInfo = $HealthStatusSystem.Runtime.SystemHealthInfo
ForEach ($Sensor in $SystemHealthInfo.NumericSensorInfo) {
 $Report = "" | Select-Object VMHost,Sensor,Status,Reading
 $Report.VMHost = $VMHostName
 $Report.Sensor = $Sensor.Name
 $Report.Status = $Sensor.HealthState.Key
 $Report.Reading = $Sensor.CurrentReading/100
 $Report
}

VMHost                   Sensor                 Status                     Reading
______                   ______                 ______                     _______
esx01.mishchenko. . .  System Board 28 . . .  green                           49
esx01.mishchenko. . .  System Board 40 . . .  green                        -11.9
esx01.mishchenko. . .  System Board 37 . . .  green                        12.29
esx01.mishchenko. . .  System Board 39 . . .  green                         5.08
esx01.mishchenko. . .  System Board 31 . . .  green                         4624
esx01.mishchenko. . .  VMware Rollup He. . .  green                            0
esx01.mishchenko. . .  Management Contr . . . green                            0
esx01.mishchenko. . .  American Megatre . . . green                            0

When you are connected to vCenter Server, the vSphere client no longer displays host health data on the Configuration tab. Rather, this data is now shown on the Health Status tab and the depth of information and functionality of the tab has expanded over what is available when directly connected to the host.

Figure 6.24 shows the hardware status for the same host as was shown in Figure 6.23. The Hardware Status tab includes a System Summary section showing the host’s BIOS version, model, serial number, asset tag, and quantity of warnings or alerts. The sensor data is more detailed as well. Figure 6.24 shows the actual temperature for the host’s motherboard along with defined threshold values. The Sensors view also provides access to the server’s IPMI event log and for this host information about the Baseboard Management Controller’s IP configuration and Media Access Control (MAC) address. You can expand or minimize the data shown in the Sensors view by clicking on the following links: Show All Sensors, Show All Details, and Hide All.

Figure 6.24. Viewing the Hardware Status page for a host when connected to vCenter Server.

The Hardware Status tab also includes two views that are not available when directly connected to your ESXi host. These are the Alerts and Warnings view and the System Event Log view. The Alerts and Warnings view filters all sensor data to display only those sensors that are registering a warning or alert condition. The System Event Log view displays the data in the host’s IPMI system log. You can click the Reset Event Log link on that view to clear the IPMI log.

The data supplied in these views is updated every five minutes. You can click Update to update the data manually. Some host hardware sensors display data that is cumulative over time. Click the Reset Sensors link to clear the data for those sensors and begin collecting new data. Hardware Status tab views also include the option to print the data shown or to export the data to an XML file.

Before you begin to install Data Recovery, you should estimate the amount of storage your deduplication stores will require. Each Data Recovery appliance can have two stores each up to 1TB. The total storage you allocate depends on the number of virtual machines you plan to back up, the frequency of backups, and the length of time backups are stored. You should allocate additional free space, which Data Recovery requires for overhead items such as indexing and restore point processing. For initial setup, you should provide a store that is equal to the amount of used disk space within your virtual machines. If you plan to backup 50 virtual machines that all have 40GB virtual disks that are approximately 50 percent full, you should allocate approximately 1TB of storage for your deduplication store.

You’ll begin the installation process with the VMware Data Recovery plug-in. On a workstation where you have the vSphere client installed, insert the Data Recovery installation CD and start the installer for the Data Recovery plug-in. Once the installation is complete, you can start the vSphere client and log in to vCenter Server. You should see the VMware Data Recovery icon under Solutions and Applications on the Home page if you have successfully installed the plug-in.

The next step for the installation process is to add the Data Recovery appliance. This is supplied on the installation CD within the VMwareDataRecovery-ovf folder. The image is supplied in the Open Virtualization Format (OVF) format so you can select File > Deploy OVF Template to import the appliance into your vCenter infrastructure. The Data Recovery appliance needs access to port 902 on your ESXi hosts, so plan the network configuration for the appliances to allow that connectivity.

The storage you use for your backup data can be on network storage or virtual disks attached to the Data Recovery appliance. If you plan to use virtual disks, edit the setting for the appliance and add the disk. You can add up to two virtual disks no larger than 1TB each.

Once you have completed the installation steps, you are ready to configure the Data Recovery appliance and connect it to vCenter Server. To configure the Data Recovery appliance, use the following process:

The Data Recovery appliance is now connected to vCenter Server and ready to perform backups.

To set up a backup job, you can use the Getting Started Wizard link found on the Configuration tab, as shown in Figure 6.28. The wizard will guide you through the following steps:

Figure 6.28. The VMware Data Recovery plug-in configuration tab.

Once you have created your backup job, you select the Backup tab to view the status of the job. On that tab, you can edit the job, create new backup jobs, and delete existing jobs. You can manually start a backup job by right-clicking on the job and selecting Backup Now. On the Configuration tab shown in Figure 6.28, you can review details for the Data Recovery appliance, manage backup stores, view the time configuration for the appliance, and review the backup log.

VMware Data Recovery supports restoring virtual machines and virtual disk files as well as individual files from Linux and Windows virtual machines. If you are restoring at the virtual machine level, you have the option to perform an actual restore of the virtual machine or you can run a rehearsal restore, which restores the backup data to another virtual machine to ensure that your backup data is consistent.

To perform a complete restore of a virtual machine, you begin by selecting the virtual machines to restore on the Restore tab of the Data Recovery screen. Then click the Restore link to begin the Virtual Machine Restore Wizard. The first screen of the wizard allows you to select the restore point to use. On the Destination Selection screen, you can change the virtual machine name; select the datastore to be used; and select a host, cluster, or resource pool in which the virtual machine will reside. You can also choose to power on the virtual machine after the restore is completed and whether the virtual network adapter for the virtual machine should be connected or disconnected. The Ready to Complete screen summarizes your restore options and displays how many virtual machines will either be created or overwritten. You can click Restore to begin the restore process. To monitor the progress of the restore job, select the Reports tab and view the Running Tasks report.

A rehearsal restore follows a process similar to the preceding one for restoring a virtual machine. To begin this process, you have to right-click on the virtual machine and select Restore to Most Recent Backup Rehearsal. The same Virtual Machine Restore Wizard runs, but in this case the virtual machine is automatically renamed, you have to select a datastore for the restore files, and the network adapter is set to be disconnected after the restore.

Restoring an entire virtual machine or disk file can be time consuming and cumbersome, and in some cases you may only need to recover a specific set of files. File Level Restore (FLR) provides a way to access individual files within a restore point for Linux and Windows virtual machines. With the FLR client, you can easily extract files from a backup and restore the files to the original or an alternative location.

The FLR client can be found on the Data Recovery installation CD. For the Linux client, you simply extract the TGZ file and execute the client. On Windows, you simply run the executable to start the client. Once the client has started, it can be run in one of two modes. In its regular mode, the FLR client connects to Data Recovery appliance and you can mount a restore point taken for the virtual machine on which you are running the client. If you check the Advanced option on the login screen, you can connect to vCenter Server to enumerate a list of virtual machines that have been backed up by the specific Data Recovery appliance.

After you have selected the mode to run the FLR client in, click Login to connect. You will then see a list of available restore points and virtual disks to use. If you have connected in Advanced mode, you can browse the navigation tree to find the virtual machine from which you want to restore files. Once you have selected the virtual disk to restore files from, click Mount. In Figure 6.29, the FLR client is running in regular mode on a Windows 7 virtual machine. A restore point has been selected and it is now mounted to the operating system at C:2010-05-03 02.00.01.

Figure 6.29. Mounting a restore point with the FLR client.

Once a restore point is mounted, you can use any operating system tool to access the files in the restore point. The tools that you use have only read-only access to the files in the mounted restore point. If you’re accessing restore points for another OS, your OS must be able to mount natively the file system that was used by that virtual machine.

Once you have completed restoring your files, you can click Unmount and then exit the FLR client. If necessary, you can mount multiple restore points and then click Unmount All to detach all the restore points that you have used.