Rescan for new LUNS from XP24000 .... Not showing up ... ?

[vmware_lic]

We are running ESXi 3.5Build 158869 ... on a DL585 G2 with ( Emulex - LPe1150 4GB Fibre Cards - Firmware Version: 2.72A2 ) ... and have LUNS presented to it from a HP EVA 5000 and HP XP24000 ... and they work fine .

The issue I have is, after a rescan of the HBA's I can see the new LUN presented from the EVA but not the XP ... The XP lun will only show up if I reboot the ESX Server ( not a good long term solution... ) ..

.. this happens every time ...

I see no errors in the logs .. Have opened a call with VMWARE .. so far nothing from them .. They are saying they see no errors...

Any thoughts help on this would be great

Thanks

[Chamon]

I am assuming that all of the LUN's have different LUN ID's. Do you see the LUN's show up when you do a rescan from the service console?

esxcfg-rescan vmhba1

esxcfg-rescan vmhba2

?

[vmware_lic]

Yes the LUN IDs are different .. and have doubled checked that ...

.. and no the LUNS do not show up when I do a

esxcfg-rescan vmhba1

esxcfg-rescan vmhba3

[Chamon]

I have had

vmkfstools -s vmhba#

work when esxcfg-rescan did not. May be worth a try.

[vmware_lic]

Thanks for the quick response ...

just tried...

vmkfstools -s vmhba1

vmkfstools -s vmhba3

.. No luck ...

Thinking of just rebooting .. do not like the idea ... but just might have to ...

[Chamon]

With our EMC sometimes it took a lot of rescans and some time for the new LUN to show. How long have you waited? Shouldn't have to but.....

[vmware_lic]

Its been more then a day and I have probably rescanned it 6 or 7 time.. actually even more ...

.. I just rebooted the server and the XP LUNS showed up fine .. Who knows ... Makes no sense ... but need to find a solution sooner then later .

Thanks

[jbruelasdgo]

are the LUNs new? or replicas?

Jose

[vmware_lic]

I have had the issue with new LUNS from a XP SAn and with XP LUNS that already exist and have been formatted as VMFS on another ESX server that I want on this new ESX box ...

Thanks

[kjb007]

If you have existing LUNs from one target, and you are adding a 2nd target, the LUN id's have to be higher than your existing LUNs, otherwise, a rescan won't always show you your LUNs, but a reboot usually does not care about the LUN order. It will poll and retrieve information on all targets and LUNs on them. I had an issue with a particular array type that would always start numbering LUNs at 0, but my existing LUNs were started at 20+, so the first time I added LUNs from that 2nd array, I had to reboot, because I could not set the LUN id's higher than what I already had.

-KjB

VMware vExpert

[Chamon]

So the LUN IDs don't have to Mach what is in the target? When you

rebooted how would the LUNID be set?

On May 1, 2009, at 9:46 PM, kjb007 <communities-emailer@vmware.com

[Chamon]

If both targets have LUN id's of 1-9 it can mount them after a reboot

On May 1, 2009, at 9:46 PM, kjb007 <communities-emailer@vmware.com

[kjb007]

Yes, as long as they come from a different array, they will have a new target number which will differentiate between the two.

For example:

If the LUN is 0 coming from the first array, it will be something like vmhba0:0:0:0, LUN 0 coming from the second array, it will be like vmhba0:1:0:0.

This can get confusing if you don't know which target is which, so it's better to have unique IDs all across the environment, but that's not always possible. But, you will need to make sure they are at least unique within the array itself.

-KjB

VMware vExpert

[Chamon]

The path is unique so it can see it. Will all of the hosts see target

1 as target 1? If so is this due to the way it is zoned? So if you are

not presenting to all of the host as a group or the same way you can

run into big problems I would think. Never had more than one target so

sorry if the question are basic.

On May 2, 2009, at 7:03 AM, kjb007 <communities-emailer@vmware.com

[kjb007]

The order the arrays are added seen by ESX host is the order they'll show up on ESX. Only the initial scan matters, as ultimately the LUNs will be referenced by UUID. The ESX host will see the target the same number, but a second host may see them the other way around, but it will be unique to that host, so it can get confusing. That's why consistency is important, and unique ID's is the best way to go.

-KjB

VMware vExpert

[depping]

it's not even using the LUN id anymore to identify the LUN. It will be using the NAA identifier... which is unique.

Duncan

VMware Communities User Moderator

-

---

Blogging:

Twitter:

If you find this information useful, please award points for "correct" or "helpful".

[CITITECHS]

We also have the same HP array's and also have to reboot host to bring in storage which is annoying.

To avoid a reboot I sometimes unload the HBA driver after I put a host into maintenance mode. We use Qlogic cards

vmkload_mod -u qla2300_707

If you have HP Insight Agents installed you need to stop the agents in order to unload the HBA driver.

Not to hijack the thread but when storage is presented to a host shouldnt the host see an RSCN prior to a rescan ? in vmkernel

I remembered working with EMC Arrays and not having to reboot the host everytime I wanted to bring in storage. But then again I didnt have to bring in storage from different array's. I would present storage and rescan and I would see what I presented right away.

[kjb007]

I've seen the same behavior from HDS as well. The issue I've always seen is if the new Lun ID being presented is lower than what you have, then a rescan will not pick it up. That may be a linux thing as opposed to an ESX thing, but does not manifest during a reboot.

-KjB

VMware vExpert

[Chamon]

But this is only an issue when dealing with multiple targets correct?

[kjb007]

That is correct.

-KjB

VMware vExpert