VCEM Profile Failover and Profile Moves

Using Customized Scripts to initiate Failover

Administrators may choose to create customized scripts or batch files to initiate Failover.

These scripts can be logically constructed to perform tasks prior to a VCEM Profile Failover

and after a VCEM Profile Failover. The basic construction of a custom script could be:

• Pre-Failover Commands. Some examples include:

o Evacuate Virtual Machines from an ESX Host

o Gracefully shutdown an application

o Write volatile data to disk

• VCEM Failover command. Using one of the following:

o vcem –failover –host hostname

o vcem –failover –ip ip_address

o vcem –failover –bay enclosure_name:bay_number

• Post-Failover Commands. Some examples include:

Import Virtual Machines to an ESX Host

Create Trouble ticket for source system maintenance

Send email to administrators notifying them that a failover has occurred

These custom scripts may be used to create a Systems Insight Manager Custom Task and

combined with the aforementioned action-on-events so that they may be initiated by system

health events. See the Systems Insight Manager User Guide for more detailed information

concerning Custom Tasks.

Using a remote system to initiate Failover

Remote Monitoring and VCEM Profile Failover

If an administrator is using a remote system to monitor servers, VCEM Profile Failover is still

possible. An example could be where one system is being used to monitor server health

and another system is running the VCEM implementation. Monitoring systems remotely

means that SIM’s Discovery is not set to run automatically at periodic intervals on the VCEM

system. This means that VCEM will not have access to reliable information about servers

such as hostnames or ip addresses. For this example, the administrator may still use the

VCEM CLI, specifically the enclosure:bay nomenclature.

Using the Enclosure:Bay CLI

The enclosure:bay cli invocation can be used if another system is used to monitor and

inventory systems information. The administrator will need to derive some way to access the

CLI which will be running on the VCEM system. SSH would be a logical choice. Once the

remote system has logged into the VCEM system, it may invoke the VCEM CLI with the

enclosure and bay of the defective server.