“Virtual Disk ‘hard disk 0’ is a mapped direct access LUN and its not accessible”


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”

LUN Name LUN ID   ESX01
Staff-DB1-H

5

naa.6006016086f0250054536426c29ce011                            vml.02000500006006016086f0250054536426c29ce011524149442035
LUN Name LUN ID   ESX02
Staff-DB1-H

5

naa.6006016086f0250054536426c29ce011                            vml.02000500006006016086f0250054536426c29ce011524149442035

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.

LUN Name LUN ID   ESX01
Staff-DB1-H

5

naa.6006016086f0250054536426c29ce011                            vml.02000500006006016086f0250054536426c29ce011524149442035
LUN Name LUN ID   ESX02
Staff-DB1-H

5

naa.6006016086f0250054536426c29ce011                            vml.02000500006006016086f0250054536426c29ce011524149442035

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

MAIL001

Completed

Administrator

26/07/2011 20:51:36

26/07/2011 20:51:36

26/07/2011 20:53:13

Advertisements

, , , ,

  1. Leave a comment

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: