Adding new ESX host to farm, vmhba path naming not consistent - existing LUNs can't be added

[Lukeitcs]

Hey all,

So I've recently installed ESX 3.0.2 onto a host that I now want to add into my ESX 3 farm (all hosts in the farm are 3.0.2). Adding the new server to the Data Center object worked fine. Getting the networking configured to be identical to the three hosts in the farm was fine too. However, when trying to add existing LUNs that are used by the hosts in the farm to the new host, 7 of the 11 show up no problem, however 4 of them do not get added.

A few weeks ago, I had 4 LUNs removed from the farm which left a gap in the VMHBA Path numbering. Those paths whose names are inconsistent between the hosts in the farm and the one I'm trying to add are the ones that do not automagically show up when I "Rescan...". On the new host, I can attempt "Add Storage..." (on the Storage config tab) and when trying that I see the 4 LUNs in question, however when trying to add them I'm warned the data will be wiped out - which is not an option.

Here's the mapping from the new host I'm trying to add them to:

vmhba0:0:0 /dev/sda

vmhba0:1:0 /dev/sdb

vmhba1:0:0 /dev/sdc

vmhba1:0:1 /dev/sdd

vmhba1:0:2 /dev/sdf

vmhba1:0:3 /dev/sdg

vmhba1:0:4 /dev/sdh

vmhba1:0:5 /dev/sdi

vmhba1:0:6 /dev/sdj

vmhba1:0:7 /dev/sdk

vmhba1:0:8 /dev/sdl

vmhba1:0:9 /dev/sdm

vmhba1:0:10 /dev/sde

And here are the mappings as they exist for the same LUNs on the existing hosts in the farm:

vmhba0:0:0 /dev/sda

vmhba1:0:0 /dev/sdb

vmhba1:0:1 /dev/sdc

vmhba1:0:2 /dev/sdd

vmhba1:0:3 /dev/sde

vmhba1:0:4 /dev/sdf

vmhba1:0:5 /dev/sdg

vmhba1:0:6 /dev/sdh

vmhba1:0:11 /dev/sdi

vmhba1:0:12 /dev/sdj

vmhba1:0:13 /dev/sdk

vmhba1:0:14 /dev/sdl

The devices names are also different, though I don't believe that matters in the larger scheme of things. And while I'm not 100% sure the path names are the culprit, I don't see anything else that would dis-allow the adding of the LUNs to the new host unscathed. As I said, the LUNs mapped to vmhba1:0:0 through vmbha 1:0:6 show up just fine, it's those last four with the different path names that are not coming up on the new host.

Any idea how to resolve this? And thanks for any suggestions!

[vJG]

Definitely pay attention to the warning, you don't want to

add storage that is already in use and formatted with VMFS. If they are not

showing up with a rescan, reboot the ESX host (you've probably already done

that though). After reboot, does the ESX host service console login screen say

anything about Resignatures or SnashotLUN? There are some references to this that

I have seen before with instructions at .

[vJG]

Assuming I'm reading you post correctly, it is the LUNS id: 11-14 that should be showing up on your new host? As long as they are presented with the same ids (11-14) you should be good. The last blade I set up did need the reboot. The rescan usually picks it up but not always.

[Lukeitcs]

Ideally, yeah, they would be 11-14. But I would settle for having the three hosts have their luns renamed to 7-10, either way would work.

[vJG · Accepted solution]

LUNS should be presented with the same ID across all ESX hosts that need to access them. The easiest is to have the 4 LUNs presented to your new host at ID 11-14. You could have them all re-presented but your other 3 hosts would have to have all their VMs be powered off first. Depends on your situation whether or not your existing servers can be down.

[Texiwill]

Hello,

Having different vmhba#'s will not affect ESX just how it looks to you. ESX uses a UUID written to the LUN to identify the VMFS in use and its mapping to your Simple Name. I have misnumbered vmhba devices and it does not affect the performance of the system in any way. Nor has it affected backups, or anything else. Yes, I have to pay close attention when doing things from the command line but that is the only issue. As long as the LUN IDs are presented as the same ID to each host you are in good shape.

Best regards,

Edward L. Haletky, author of the forthcoming 'VMWare ESX Server in the Enterprise: Planning and Securing Virtualization Servers', publishing January 2008, (c) 2008 Pearson Education. Available on Rough Cuts at http://safari.informit.com/9780132302074

[Lukeitcs]

Well, in this case as it seems to be in many others, the trailing vmhba# is the same as the LUN ID so while it may be possible to have mismatching vmhba #s, as you say the LUN IDs must be the same.

I opened a ticket with support last week and they are under the impression that this ID can be adjusted by my SAN guys - which they verify that it can be. So, I've had them adjust the LUN IDs on the the four LUNs in question and re-present them to the host I'm trying to add to the cluster/farm. I've just powered up the host, rescanned for LUNs/VMFSs and they now appear as expected and are working normally.

Thanks to all how replied to this thread.

[robertg1]

Hi All,

Need to be careful on assumptions hear, Yes these mappings shown by "esxcfg-vmhbadevs" and the difference in all Hosts in a cluster do not affect VFMS datastores due to the LUN ID reference in the VMFS metadata, BUT these mapping difference definitely do affect Guests with RDM's, as you will see in the guest edit setting dialog box the RDM are referenced by the "vmhba1:x:x" number, if there different on each or even one ESX server in the cluster you will have vmotion issues. I've experenced this issue with RDM's a number of times. Resolve is to sort out the SAN LUN allocations/assignments make sure there the same of each Host in the cluster.

RobertG