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
•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
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
92
