Practices Guide

Active System Manager Virtual Appliance Best Practices for VMware
6
reservations that fully commit cluster capacity can prevent DRS from migrating virtual machines
between hosts.
The Active System Manager appliance requires a minimum of two virtual CPUs (vCPUs); however, it is
important to make sure that the total number of vCPUs assigned to all VMs does not utilize more than
80% of the ESX host’s CPU.
Minimizing use of the Memory Balloon driver, as well as swapping, requires allocating 8GB of reserved
RAM.
Backing Up and Restoring the Virtual Appliance
To simplify backing up Active System Manager, it is recommended to run the Active System Manager
virtual appliance from centralized storage.
One back-up strategy is to configure the storage array shared volume that contains the Active System
Manager OVF to automatically create and manage nightly snapshots (this process differs from the VM
snapshots described in the next section). It is recommended to keep at least one week’s worth of
snapshots.
An alternate strategy is to configure real-time array replication between two or more storage arrays.
Although the replication can be local, the best practice is to replicate between two separate data
centers.
For detailed information on how to backup and restore the Active System Manager appliance, see the
Active System Manager User Guide.
Virtual Machine Snapshots
NOTE: It is important to understand that VM snapshots alone are not an adequate backup strategy.
A snapshot is a virtual disk change log that is useful for preserving a VM’s state and data at a specific
point in time. It includes data such as power states and the files that comprise a virtual machine.
It can be helpful to think of a snapshot as temporary storage space. A new VM starts with a base
temporary file (server-flat.vmdk). Creating a new snapshot and making changes to the server creates a
new temporary file (server-000001.vmdk). Taking another snapshot creates another temporary file
(server-000002-delta.vmdk)—all subsequent changes are saved to this new snapshot file. For example:
Base Disk -> server-flat.vmdk
Snapshot 1 -> server-0000001-delta.vmdk
Snapshot2 -> server-000002-delta.vmdk
All snapshots reference previous snapshots and the base disk (server-flat.vmdk) using a child ID (CID)
and parentCID. For example:
The base disk (server-flat.vmdk) has a CID of 1234ABCD.
Snapshot1 (server-000001-delta.vmdk) has the parent CID of 1234ABCD and a unique CID (8-
digit HEX).
Snapshot 2 has a parentCID equal to the unique 8-digit HEX CID number of Snapshot1.