Massimo, thanks for the swift reply.
But surely by enabling LVM.EnableResignature I will be forcing the LUN on to a new UUID, and therfore have the hardcoded UUID's in the .VMX problem... Or will the VMX file auto update?
How would this work with a unique VC between Primary site and DR?
I didn't have much time to look into the details of this so I don't know the exact answer to your question.
The only thing I can tell you is that during the migration to 3.x of this setup
(the scenario that uses the storage remote copy .... not the veritas volume manager mirror......) .... we have found a bit of problems due to the fact that after re-activating the LUN on the secondary storage server the ESX 3.x servers were not "quite sure about what to do" (i.e. whether to treat the LUN as if it was the actual old VMFS or a brand new VMFS volume). Of course we wanted the first and the usage of the LVM.EnableResignature made the trick.
Unfortunately I was not "at the keayboard" for these tests so I am not sure what happened under the covers but it is my understanding that it's a "transparent" thing .... the VMX won't be updated ..... it's just the VMKernel that is suggested to treat the new LUN as if it was the old one. In fact for the VMKernel this is not a COMPLETELY new LUN .... it understands it is similar to the old one but NOT exactly the same .... hence the confusion .... hence the forcing to treat it like if it was the old original LUN.
I understand you were looking for a "0 and 1" response while this seems more like a poem ...... but this is what I have to offer ......
Your opinion and expert knowledge is always welcome
I will be able to do a little testing with this prior to a DR go live, hopefully I'll be able to bottom this out then.
I'm kinda glad that my concerns aren't new, I guess I'm really tried to avoid a scenario where I have to remap VMDK devices on several thousand VMs in event of a DR scenario...
I'll place a quick call with my friendly local VM rep I think.
1 person found this helpful
>I'm kinda glad that my concerns aren't new, I guess I'm really tried to
>avoid a scenario where I have to remap VMDK devices on several
>thousand VMs in event of a DR scenario...
We have more than 900 vm's on that setup ..... if we were to change the VMX files on all of them because of this we would have thrown VI3 out quickly .....
There is a TSX presentation that explains this in details though ...... It's the "Top_Support_Issues_-_part1" here:
Massimo, thanks for the information in the presentation. Some of the slides are gold
especially the following information;
You can present a snapshot VMFS-3 volumes to a different ESX Server host using 2 options:
EnableResignature or DisallowSnapshotLUN.
To allow snapshot LUNs, set:
EnableResignature to 0
DisallowSnapshotLUN to 0
Do not use DisallowSnapshotLUN to present snapshots back to same ESX server as the original LUN.
Unpredictable results can occur since you will have 2 LUNs with the same UUID.[/i]
And the diagram on slide 25.
I'd still welcome any comments from other folk running this