vSphere 5.5 Storage Enhancement Part 7 – LUN ID/RDM Restriction Lifted

About a year ago I wrote an article stating that Raw Device Mappings (RDM) continued to rely on LUN IDs, and that if you wished to successfully vMotion a virtual machine with an RDM from one host to another host, you had to ensure that the LUN was presented in a consistent manner (including identical LUN IDs) to every host that you wished to vMotion to. I recently learnt that this restriction has been lifted in vSphere 5.5. To verify, I did a quick test, presenting the same LUN with a different LUN ID to two different hosts, using that LUN as an RDM, and then seeing if I could successfully vMotion the VM between those hosts. As my previous blog shows, this failed to pass compatibility tests in the past. Here are the results of my new tests with vSphere 5.5.

For this test, I used an EMC VNX array which presented LUNs over Fiber Channel to my ESXi hosts. Using EMC’s Unisphere tool, I create two storage groups. The first storage group (CH-SG-A) contained my first host, and the LUN was mapped with a Host LUN ID of 200 – this is the id that the ESXi host see the LUN.

My next storage group (CH-SG-B) contained my other host and the same LUN, but this time the Host LUN ID as set to 201.

Once the LUNs were visible on my ESXi hosts, it was time to map the LUN as an RDM to one of my virtual machines. The VM was initially on my first host, where the LUN ID appeared as 200. I mapped the LUN to my VM:

I proceeded with the vMotion operation. Previously version of vSphere would have failed this at the compatibility test step, as per my previous blog post. However, this time on vSphere 5.5, the compatibility test succeeded even though the LUN backing the RDM has a different LUN ID at the destination host. I completed the vMotion wizard, selecting the host that also had the LUN mapped (you can only choose an ESXi host that has the LUN mapped) and the operation succeeded. I then examined the virtual machine at the destination, just to ensure that everything had worked as expected, and when I looked at the multipath details of the RDM, I could see that it was successfully using the RDM on LUN ID 201 on the destination ESXi host:

So there you have it. The requirement to map all LUNs with the same ID to facilitate vMotion operations for VMs with RDMs has been lifted. A nice feature in 5.5.

Note: While a best practice would be to present all LUNs with the same LUN ID to all hosts, we have seen issues in the past where this was not possible. The nice thing is that this should no longer be a concern.