92
If you use Fibre Channel shared storage with LUN mirroring to replicate the data to the
secondary site, before you attempt to recover data, mirroring must be broken so that the
secondary site has Read/Write access.
3. Select the storage repositories (SRs) containing the pool metadata for the VMs and vApps that you want
to recover.
By default, the list on this wizard page shows all SRs that are currently attached within the pool. To scan for
more SRs, choose Find Storage Repositories and then select the storage type to scan for:
• To scan for all the available Hardware HBA SRs, select Find Hardware HBA SRs.
• To scan for software iSCSI SRs, select Find Software iSCSI SRs and then enter the target host, IQN and
LUN details in the dialog box.
When you have selected the required SRs in the wizard, click Next to continue.
4. Select the VMs and vApps that you wish to recover then click Next to progress to the next wizard page and
begin failover prechecks.
5. Before beginning the test failover process, the wizard performs a number of pre-checks, for example, to
ensure that all the storage required by the selected VMs and vApps is available.
•Check that storage is available If any storage is missing, you can click Attach SR on this page to find and
attach the relevant SR.
•Check that HA is not enabled on the target DR pool. To avoid having the same VMs running on both
the primary and DR pools, HA must be disabled on the secondary pool to ensure that the recovered VMs
and vApps are not started up automatically by HA after recovery. To disable HA on the secondary pool,
you can simply click Disable HA on the this page. (If HA is disabled at this point, it will be enabled again
automatically at the end of the test failover process.)
Resolve any issues on the pre-checks page, and then click Failover to begin the test failover.
6. A progress page is displayed showing whether recovery was successful for each VM and vApp. Failover may
take some time depending on the number of VMs and vApps you are recovering, as the metadata for the
VMs and vApps are recovered from the replicated storage. The VMs and vApps are recreated in the DR pool,
the SRs containing the virtual disks are attached to the recreated VMs.
The recovered VMs are placed in a paused state: they will not be started up on the secondary site during
a test failover.
7. After you are satisfied that the test failover was performed successfully, click Next in the wizard to have the
wizard clean up on the DR site:
• VMs and vApps that were recovered during the test failover will be removed.
• Storage that was recovered during the test failover will be detached.
• If HA on the DR pool was disabled at the prechecks stage to allow the test failover to take place, it will
be enabled again automatically.
The progress of the cleanup process is displayed in the wizard.
8. Click Finish to close the wizard.
vApps
A vApp is logical group of one or more related Virtual Machines (VMs) which can be started up as a single
entity in the event of a disaster. When a vApp is started, the VMs contained within the vApp will start in a user
predefined order, to allow VMs which depend upon one another to be automatically sequenced. This means
that an administrator no longer has to manually sequence the startup of dependant VMs should a whole service
require restarting (for instance in the case of a software update). The VMs within the vApp do not have to reside
on one host and will be distributed within a pool using the normal rules. The vApp functionality is particularly