Virtual Disk ‘X’ is a mapped direct access LUN that is not accessible

After some LUNs are removed and re-presented to an ESX cluster you are unable to power on VMs or migrate them to other hosts in a cluster and see the following error:

Virtual Disk 'X' is a mapped direct access LUN that is not 
accessible

You also receive the following error when doing trying to view the properties of those RDMs when clicking Manage Paths in the Virtual Machine Properties:

There is no multipath configuration for this LUN

The cause of this issue is what is known as a VML mismtach. This occurs when the VML identifier for an RDM on two or more ESX hosts are not same – they are mis-matched. This issue is highlighted in VMware KB article 1016210.

The first thing to do is to ensure that the LUN IDs are the same across all the ESX hosts. If not, they need to be removed and re-presented so that the LUN IDs match. Secondly, you need to remove all the affected RDMs and then re-add them per the steps below:

  1. Power down the virtual machine.
  2. Right-click the virtual machine and click Edit Settings.
  3. Make note of the raw device mapped disks which are attached to the virtual machine.
  4. Remove the raw device mapped disks from the virtual machine.
  5. Click OK.
  6. Right-click the virtual machine and click Edit Settings.
  7. Click Add to re-add the previously removed raw device(s).
  8. Click OK.
  9. Power on the virtual machine and re-attempt the operation which previously failed.

I personally found that the steps above still did not resolve the issue. I then removed the RDMs and cold migrated the faulting VM to the other ESX host in the cluster and was able to add the RDMs. This identified that the cause was the previous ESX server. I power-cycled the faulty ESX server (Windows Admin style) and, migrated the VM back to it and was then able to add the RDMs successfully:

P2V fails with error: A general system error occurred

This morning I attempted to kick off a P2V (Physical 2 Virtual) conversion but when reaching the end of the wizard and clicking submit the following error appeared:

A general system error occurred

To identify the potential cause I navigated to the VMware Converter logs found in:

C:\Documents and Settings\All Users\Application Data\VMware\
VMware vCenter Converter Standalone\logs

My search yielded the following error:

[05924 error 'Default'] Found dangling SSL error: [0] 
error:00000001:lib(0):func(0):reason(1)

A quick search on Google found VMware KB article 2002296, which alluded to DNS/domain authentication being the root cause. This was not the case in this instance, name resolution was working fine. Ping and telnet tests also confirmed connectivity to the destination ESX server and the necessary ports (902 & 443). The error indicated that SSL authentication failed. This led  me to check the hosts.allow file on the ESX server and I found that the network I was connecting from had not been given explicit access. I subsequently added the following line by opening up hosts.allow using vi editor:

[root@esx1 ~]# vi /etc/hosts.allow

I then added the following line to the top of the file:

ALL : ALL

This gave all IPs access to all services on this ESX server. Ordinarily this is not good security practice however as the ESX server was within a secure environment it was safe to do this.

I then restarted the network services which committed/effected the change:

[root@esx1 ~]# service network restart
Shutting down interface vswif0:                            [  OK  ]
Shutting down interface vswif1:                            [  OK  ]
Shutting down loopback interface:                          [  OK  ]
Bringing up loopback interface:                            [  OK  ]
Bringing up interface vswif0:                              [  OK  ]
Bringing up interface vswif1:                              [  OK  ]
[root@esx1 ~]#

It is also worth mentioning that you should check the hosts.deny file and comment out any entries that may affect your ability to connect to services hosted on ESX.

I then re-submitted the P2V conversion job and it started running successfully:

If this works for you, remember to revert the hosts.allow file once your P2V work has completed.