Quick question,
Currently how do you manage differing UUIDs between the Primary and DR sites?
Specifically I'd like to hear about experiences with IBM Hardware, DS 8300 and DS 4700 SAN infrastructure and Global Mirror/ Metro Mirror.
The UUID is derived from FOUR parts;
1. Creation time in seconds since 1-1-1970
2. The TSC Time; an internal time stamp counter kept by the CPU.
3. Random Number
4. MAC Address of Server that formatted the VMFS volume
This would mean that the UUIDs of the LUNs presented in DR will always be different then the primary site.
My concern is that with the UUID being hardcoded inside the VMX file, in DR invocation there is a large degree of manual work to repoint the VM to it's target VMDK files etc...
Any thoughts?
>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:
http://www.vmware-tsx.com/index.php?page_id=10
Massimo.
See this:
http://www.vmware.com/community/message.jspa?messageID=364352
Massimo.
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?
Simon
Simon,
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
http://it20.info/files/3/documentation/entry2.aspx
(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 ......
Massimo.
Hi Massimo,
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.
Simon
>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:
http://www.vmware-tsx.com/index.php?page_id=10
Massimo.
Massimo, thanks for the information in the presentation. Some of the slides are gold :smileygrin:
especially the following information;
Allowing Snapshot VMFS-3 Volumes to be seen by a different ESX
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.
Thanks.
I'd still welcome any comments from other folk running this