asked on
VMware signature
I have a storage system that replicates volumes to the DR's array. Everything works fine. Yesterday, I performed a test run to mount the DR's LUN to the ESXi hosts. Two options popped up when I tried to mount the LUN: 1) Assign a new signature, and 2) Keep the existing signature. My understanding is that both should work since the LUN is away from the production ESXi cluster, but I might be wrong. I chose to assign a new signature, and the mounted LUN is now called 'snap888888444-MYVOL,' while the source LUN is named 'MYVOL.' I was able to spin up the VM. Now, I need to fail back. Should I still choose to keep the existing signature or assign a new one? I would appreciate it if someone could explain which option is suitable in which situation.
ASKER
I choose the no-signature option on the target when I failedover. Everything was fine. Then I failedback to the source it did not ask me whether I want to signature or not. I noticed the volumes showed as inaccessible on the ESXi hosts and zero size I had to right-click and select the mount option then it showed with the correct size. Is there any reason it did not ask me whether I want to designate?
what does your failedback do ? does the SAN replicate from DR to Production again ?
No re-sig no changes to LUN.
So if no changes were made, it's the same, so surprised any issues.
ASKER
Yes, SAN replicate to production. Initially the SAN replicates from Production to DR. I performed a failover and failback. When I perform failover, the DR SAN will become the temp production and replicate back to the original source.
In the event of a DR situation Keep the signature
It’s just ESXi method of protection because it recognises these LUNs are from a snapshot of the LUN