Mismatch LUN IDs in RDM LUNs

Can you verify that the LUN IDs are being presented correctly from the array?

Disclaimer: All of your typos are belong to iPad.

hello  Scherer,

Thanks for your reply. I have verified that many times and I made sure also only those LUNs are presented to the Host, even though I'm having the same issue.

Also, I have tried with two LUNs that already presented to the ESX01 and mapped to the VM as an RDM. When I presented these LUNs to the ESX02, I got different LUN IDs but same WWN. What a strange issue.

Hello,

The following test I have carried out on a test VM and test RDM LUN but didn't help;

• Created test VM
• Created test RDM LUN and  attached to both ESX Hosts.
• Both hosts sees the LUN with different LUN ID but correct WWN.

ESX-Host02

• DGC iSCSI Disk (naa.60060160daf125005e0895f314b5e011)
  naa.60060160daf125005e0895f314b5e011
  vmhba43:C0:T0:L8
  8 LUN ID
  disk
  iSCSI
  10.00 GB
  NMP
  Unknown

ESX-Host01

DGC iSCSI Disk (naa.60060160daf125005e0895f314b5e011)
naa.60060160daf125005e0895f314b5e011
vmhba43:C0:T0:L24
24 LUN ID
disk
iSCSI
10.00 GB
NMP
Unknown

I attached to both hosts at the same time and I did re-scan. Both LUNs show up but with different LUN IDs

I attached to ESX02 first and as Virtual RDM and I attempt to vMotion, I got the error Mapped Direct-Access LUN that is not accessible.

I removed the RDM and as you suggest and Deleted from Virtual Machine and delete files from Disk.

I added again and I choose an RDM instead of Existing Disk Mappers. But no joy

What other things could be the issue? ESX host? it seems it takes the LUN ID based on Incremental Number not based on the SAN LUN ID.

It appears that you have separate Navisphere/Unisphere storage groups for each of your ESX servers which is not wrong (for instance this is required if you were booting the ESX hypervisor from SAN); however, it is imperative that when adding the RDM LUNs to each storage group that the Host ID (HLU) match exactly for shared storage.

In the case of: ESX-Host02

vmhba43:C0:T0:L8

You would find in your Navisphere/Unisphere storage group that the LUN was added and assigned Host ID: 8

In the case of: ESX-Host01

vmhba43:C0:T0:L24

You would find in your Navisphere/Unisphere storage group that the LUN was added and assigned Host ID: 24

The LUN ID as seen in ESX(i) matches the Host ID of the LUN as seen in the Navisphere/Unisphere storage group properties.  Keep in mind the following:

a) When you add LUNs to the Navisphere/Unisphere storage group, it will be auto-assigned the next available Host ID

b) Or, as you add LUNs to the storage group, you can click into the column Host ID and manually assign them via the pull-down menu that appears

c) Once assigned, you cannot dynamically change it.  You must remove the LUN and add it back to the storage group

Solutions:

1) Unless you have a need to present unique LUNs to one or more (but not all) servers in the ESX cluster, then:

a) Create one storage group: "ESX Cluster" for instance

b) Assign all of your registered hosts in the same cluster

c) Add shared LUNs to storage group

Keep in mind the following rules in Navisphere/Unisphere regarding storage groups:

a) A host can not be in more than one storage group

b) Multiple hosts can be assigned to the same storage group

c) A LUN can be in more than one storage group

2) If you need to present unique LUNs to one (but not all) servers in the ESX cluster, for instance booting the hypervisor from SAN, then your decision is made for you and you must use separate storage groups as it appears you are using now; however, again, the Navisphere/Unisphere storage group Host ID assignment for the shared (RDM) LUNs must match as mentioned above.

Message was edited by: Christopher Imes UPDATE: In consideration of anyone that might stumble on this post last updated 6 months ago, with the release of ESXi 5, this is no longer a requirement; however, still remains true for ESX/ESXi 4 as was the context of this post at the time.

Hi,

Here’s an update for this issue.

Problem:

vMotion is not possible and when I attempt to vMotion a VM I got an error

"Virtual Disk 'hard disk 0' is a mapped direct access LUN and its not accessible"

This error is generated due to LUN ID Mismatch and vml.xxx LUN Signature mismatch.

Even When I created a match LUN IDs in both hosts, still I’m presented with the error when I attempt to vMotion the VM.

What’s wrong?

Both, LUN ID and WWN name are matched in both ESX Hosts. Vml.xxx also matches each LUN in each host correctly.  In here, at least Cold vMotion should works, but in my case it’s not and when I attempt to Cold vMotion the VM again I’m getting the “Virtual Disk 'hard disk 0' is a mapped direct access LUN and its not accessible"

I have found that in the VM Properties > Mapped RAW LUN Disk > Physical LUN and Datastore Mapping File, the LUN signature / vml.xxxx is wrong and it’s not referring any LUN among all the presented LUN.

Hummmmm, something strange going in here!!

This issue happened due to using existing RDM Mapper File. J This Exchange VM was running on ESX 4.0 and all the LUNs are mapped as RDM to the Exchange VM as a Virtual Compatibility Mode. I have upgraded one of the hosts which were in the same cluster, and I added it to another cluster where it’s managed by vCenter 4.1 latest build.

The new host has access to all the LUNs which accessed by the old host. Then, I shutdown the VM remove all the RDMs and I removed it from the old vCenter inventory, after that on the new host I browsed inside the datastore where the .vmx file located and added to the new inventory on the new vCenter 4.1. When the VM comes up normally, I start adding the RDM again but this time as an existing disk from the datastore which holds the mapper files.

The problem is this part, adding an exisiting rdm.vmdk mapper file to points to a LUN that directly presented to another host, here’s the result which created all the hassle.

This shows in the VM which is running on the new host and new vCenter01. But the Physical LUN and Datastore Mapping File points / referenced to the old vml.xxx signature where the VM were running on ESX 4.0 host.

If you have noticed on the above screen shot, the same LUN “6006016086f0250054536426c29ce011 points to new   vml.02000500006006016086f0250054536426c29ce011524149442035     but on the VM properties it shows different vml.xxx ID vml.0200000000060 which doesn’t have any referenceJ

Bottom line, the solution for this is vary

1. Matching the LUN IDs across all the hosts it won’t solve the problem if the vml.xx ID is different.
2. Matching the LUN IDs across all the hosts along with the vml.xxx signature, it might solve the problem or might not. Also, the datastore which holds in the RDM Mapper File should match the LUN ID and vml.xx in the other hosts.
3. The only solution resolves this issue is
   1. Dismount Exchange Datastore to avoid any unpredictable  issue J
   2. Stop all exchange services and disable them.
   3. Shutdown the VM
   4. Remove the RDM LUNs and choose to Remove from Virtual Machine and Delete files from disk “This step won’t delete the actual Data in the NTFS LUN.
   5. Boot the VM and make sure the VM can be vMotioned using the VMDK which holds the OS only.
   6. Re-add the RDM to the VM and make sure it got all the WWN and vml.xxx matching all the hosts in the cluster.
   7. Start Exchange Services
   8. Mount Exchange Databases if they didn’t mount by itself

Result:

Migrate virtual machine

MUBMAIL001

Completed

Administrator

26/07/2011 20:51:36

26/07/2011 20:51:36

26/07/2011 20:53:13

Simply wanted to update my specific comment about matching LUN ID's (from ESX's perspective) and RDM's. 

In consideration of anyone that might stumble on this post last updated 6 months ago, with the release of ESXi 5, this is no longer a requirement; however, still remains true for ESX/ESXi 4 as was the context of this post at the time.  I was reminded of this via the following related post.

https://community.emc.com/message/586103#586103

As for the feedback that followed about matching LUN ID's, but also mismatching VML names, I want to thank Habibalby for sharing your experience with us.