Once a promotion has occurred, and the volumes are connected they can be used in a VMware environment. Though VMFS datastores will not just appear upon connection--they need to be resignatured.
A resignature is required by the volume in the newly promoted pod is a new distinct volume from its source volume. In other words the serial number of the recovered volume in pod B is different from the original production volume in pod A. VMFS has a signature--this signature is how VMware tracks the uniqueness of a file system. The signature is computed from the serial number of the underlying volume and stored in the VMFS header information. So if a file system is copied block-for-block to a new volume (as in the case of ActiveDR) when ESXi first sees this volume it will ignore it. ESXi sees a file system identifier, but it does not match the serial number of the volume hosting it. It therefore knows it has been copied--mounting a volume with a VMFS with an invalid signature could lead to data corruption (same file system, different volume) because multipathing does not know which device to send the data for that file system. Therefore in this situation ESXi requires that you first "resignature" any VMFS with an invalid signature. This updates the signature to match the serial number and allows ESXi to see it as a distinct datastore--allowing the source datastore and many, many copies to be presented at once.
For ActiveDR a promotion will take the data from the source side volumes and copy it to new target side volumes. Since this is a block-for-block copy a resignature is needed.
To resignature, login to the vSphere Client and right-click on an ESXi host or cluster and choose Storage then New Datastore.
|
1) Right-click on a host or cluster. |
2) Choose Storage, then New Datastore. |
3) Choose VMFS and click Next. |
|---|---|---|
|
|
|
|
If you chose a cluster, select a host to perform the resignature. There is no need to specify a datastore name in this case as the name will be automatically generated based on the original VMFS name. The datastores available for resignature will report the original VMFS name in the column called Snapshot Volume. Look for the datastore name you want to resignature and select it and click Next. Choose Assign a new signature.
The Assign a new signature option is not always default so be careful in this wizard. Do not select keep existing signature (as that will fail if the original is still there) and do not choose Format the disk. Format the disk will delete all of the data on the VMFS volume.
|
1) Choose a host |
2) Find the volume with the correct snapshot name |
3) Choose Assign a new signature |
|
|
|
|
Complete the wizard and click Finish.
This will resignature the datastore and it will be mounted on the hosts that see it.
As shown in the above image, the datastore will be mounted with a default name: a prefix assigned by VMware in the form of "snap-XXXXXXXX-" and the original VMFS name. There is no way to prevent VMware from adding this prefix and using the original name. Once the volume has been resignatured you can then rename it to whatever you prefer.
Right-click on the datastore, choose rename then supply the new name.
|
1) Right-click on the datastore and choose Rename. |
2) Enter a unique name and click OK. |
3) The datastore will now reflect the new name. |
|---|---|---|
|
|
|
|
The last step is to re-register and power-on the VMs. The full process to do this is beyond the scope of this document. An example:
|
1) Right-click the datastore and choose Register VM |
2) Identify the target VM folder and choose the VMX file. |
3) Specify a name and folder |
4) Choose a host |
|---|---|---|---|
|
|
|
|
|
The above process will register the virtual machine--repeat for each one you need to register. You may also need to change VM Networks, Tags, Policies, and more. This all is dependent on your environment. Consult VMware documentation for details.