VMware Cloud Community
conyards
Expert
Expert
Jump to solution

DR LUN replication?

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?

https://virtual-simon.co.uk/
Reply
0 Kudos
1 Solution

Accepted Solutions
mreferre
Champion
Champion
Jump to solution

>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 Re Ferre' VMware vCloud Architect twitter.com/mreferre www.it20.info

View solution in original post

6 Replies
mreferre
Champion
Champion
Jump to solution

See this:

http://www.vmware.com/community/message.jspa?messageID=364352

Massimo.

Massimo Re Ferre' VMware vCloud Architect twitter.com/mreferre www.it20.info
conyards
Expert
Expert
Jump to solution

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

https://virtual-simon.co.uk/
Reply
0 Kudos
mreferre
Champion
Champion
Jump to solution

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 ...... Smiley Wink

Massimo.

Massimo Re Ferre' VMware vCloud Architect twitter.com/mreferre www.it20.info
Reply
0 Kudos
conyards
Expert
Expert
Jump to solution

Hi Massimo,

Your opinion and expert knowledge is always welcome Smiley Happy

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

https://virtual-simon.co.uk/
Reply
0 Kudos
mreferre
Champion
Champion
Jump to solution

>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 Re Ferre' VMware vCloud Architect twitter.com/mreferre www.it20.info
conyards
Expert
Expert
Jump to solution

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

https://virtual-simon.co.uk/
Reply
0 Kudos