I have been asked about re-configuring replication for a VM without deleting the destination folder for a VM which is already replicated . In a traditional storage , we were simply renaming the folders on the destination datastore (Can be a local or a remote site) , we used to re-name the folder at the target site , perform a force stop replication at source and target site and simply re-configure replication to the same folder using existing seeds to avoid a full-sync between the two sites .
Things can get very complicated with vSAN as we donot have an option to directly rename the folder ,the folders which we create is merely a symlink to a UUID (NameSpace folder) on the vSAN datastore and hence we cannot rename the UUID .
Lets see an example where a VM is being replicated from primary site to the DR site using VR 8.1 . Following Example and steps applies with vSAN 6.6.x / vSAN 6.0.x with vSphere Replication 8.1.x and vSphere Replication 6.5.x .
Setup
Three node vSAN cluster running vSAN 6.7 at both Primary and Secondary Site . We are using VR version 8.1 in this illustration . We have a VM called win7 which is being replicated from source to Target Site .
VM we are going to work with is win7
Lets look at the replication configuration from Source and the destination objects at the DR site . Here we see the VMDK which is being replicated from source host p-h1.vsensei.local for the VM “win-7” which has a vDisk called win7.vmdk , replication ID for this VMDK is RDID-16d6932c-0b80-4838-bb36-f52fabf8fd97 (see on the left hand side under get-config details using command “vim-cmd hbrsvc/vmreplica.getConfig VM-ID”). On the Right side we see the datastore⇒NameSpace path where the VM is being replicated to . This contains the hbrdisks (vmdk) with respective RDID disk/ (Journal disk) i.e “hbrdisk.RDID-16d6932c-0b80-4838-bb36-f52fabf8fd97.18.39977055102374.vmdk” and the respective base disk for that VM which is in this case is again win7.vmdk (At the Target Site)
Just to show you the object attributes for the NameSpace which correlates to the vm-folder with command “esxcli vsan debug object list” against the UUID for the actual vmdk object where this pointer file “win7.vmdk” is pointing to at the DR site .Please also note that in the vSAN datastore , the pointer file will not be pointing to a “VM_NAME-flat.vmdk” like on a VMFS file system where the data gets written it actually points to an object on the vSAN file system as seen below . hence the pointer file will usually be in bytes , same applies to the HBR-RDID files who also point to a vSAN object in the backend .
[root@s-h1:/vmfs/volumes/vsan:52f056aba5df4658-8e963893c4dd02a8/1b80b15b-ef89-d8ac-63c8-005056b81125] cat win7.vmdk | grep -i vsan RW 20971520 VMFS "vsan://1e80b15b-4a58-81f4-db87-005056b880b5" Object UUID: 1e80b15b-4a58-81f4-db87-005056b880b5 Version: 6 Health: healthy Owner: s-h3.vsensei.local Policy: hostFailuresToTolerate: 1 CSN: 1 Configuration: RAID_1 Component: 1e80b15b-2cbe-a7f5-a942-005056b880b5 Component State: ACTIVE, Address Space(B): 10737418240 (10.00GB), Disk UUID: 528b4edb-a6a9-258a-572d-e75eba525740, Disk Name: naa.6000c29e66232078e9eca8c25e5b0494:2 Votes: 1, Capacity Used(B): 10007609344 (9.32GB), Physical Capacity Used(B): 9906946048 (9.23GB), Host Name: s-h1.sensei.local Component: 1e80b15b-86b6-a9f5-f986-005056b880b5 Component State: ACTIVE, Address Space(B): 10737418240 (10.00GB), Disk UUID: 5247c151-75bb-ba7d-cd70-620452e0751c, Disk Name: naa.6000c29ee707b1c208ab912d7f826646:2 Votes: 1, Capacity Used(B): 10007609344 (9.32GB), Physical Capacity Used(B): 9906946048 (9.23GB), Host Name: s-h3.vsensei.local Witness: 1e80b15b-51cc-aaf5-2984-005056b880b5 Component State: ACTIVE, Address Space(B): 0 (0.00GB), Disk UUID: 525dacfc-8968-4af9-2961-fbc18247c3fb, Disk Name: naa.6000c294eba0d6d3c3be8c3b60bda715:2 Votes: 1, Capacity Used(B): 12582912 (0.01GB), Physical Capacity Used(B): 4194304 (0.00GB), Host Name: s-h2.vsensei.local Type: vdisk Path: /vmfs/volumes/vsan:52f056aba5df4658-8e963893c4dd02a8/1b80b15b-ef89-d8ac-63c8-005056b81125/win7.vmdk (Exists) Group UUID: 1b80b15b-ef89-d8ac-63c8-005056b81125 ⇒ is the NAMESPACE Folder or the VM Folder UUID . Directory Name: (null)
Now that we know how the replication is working between the two sites where the vsphere replication happens between the two sites on a vSAN datastore at both primary and DR site . We shall see how we can re-configure replication without renaming the folder as this is not an option on vSAN datastore due to the nature of the filesystem .
Step 1
Make a note of the namespace folders (VM working directory where the vmx , vmdk etc are located ) at both primary site and the DR site .
Step 2
Force stop replication at the protected site or the Primary site .
Step 3
Create a dummy/temporary folder on the vSAN datastore at the Target or the Destination site and copy all the content from the current target replication folder to the dummy folder .
Note : It is expected that the replication status for the VM at the target-site in the incoming direction will show up as “Error state”
I preferred the SSH method to copy the content of the files from the current target destination folder to the Dummy Folder .
Step 4
Once I have copied all the folder content from the target folder to the dummy folder , I delete the content inside the original target folder , in my case it is the files inside folder “win7” at my target site .
Step 5
Now that we have moved all the files from the original folder , we are safe to force stop the replication from the incoming direction at the target site , since there are no files / vmdks on the original folder there will be no deletion task against the vmdk objects , vcenter server will also report a vmdk deletion task failure .
Step 6
Now that we have successfully stopped replication from both source and the target site . We are good to copy just the actual vmdk object , here in this case win7.vmdk from the “Dummy” folder back to original target folder . The reason we dont have to copy the other files is because when we reconfigure replication from the source site , we will create a new RDID and respective HBR-RDID vmdk for the replication session , the current files are no longer valid/required .
From the above screenshot we can see that the win7.vmdk is copied back to to the win-7 folder (Original target Folder) .
Step 7
We can now safely re-replicate the VM from the source to the same target folder using existing seeds , avoid a full-sync replication and only replicate the delta-changes to the Target .
It is good to check the status of the replication from the command line as we will still see the status on the GUI as full-sync however vSphere-Replication appliance will only be comparing the checksum data between the two VMDKs at the source and target once it finishes the checksum comparison , the replication status will go back to read state . You will also see that the amount of data transferred to the Target site will be 0 bytes.
Recap
- We can safely move the files from original target folder to a dummy folder and these file copy/movement should finish in couple of seconds as there is no data to actually copy , all files are just pointer files and not actual vmdk.
- We can safely delete the content on the original target folder
- Force stop replication from both Source and Target site , we will see the vmdk deletion task fail at the vcenter , because the Original target folder is empty .
- Next copy/move just the base disk pointer from the target folder back to the Original target folder .
- Re-configure replication for the same VM using existing seed and vsphere replication appliance will only compare the checksum before it starts to seed again to the target vmdk .
Conclusion
We are saving a ton of bandwidth usage between to sites as we do not have to do a full-sync to the target site , rather only do a simple checksum comparison and continue to re-replicate the VM using existing seed .
