VMdawg
Enthusiast
Enthusiast

HBA Rescan

Jump to solution

Everytime I delete a vdisk to host mapping through my SVC and rescan the HBA's in VC on a specific host it times out and requires a host boot for the datastores to refresh...anybody else experienced this?

0 Kudos
1 Solution

Accepted Solutions
boydd
Champion
Champion

Yes and did you know that the standard build(s) of ESX 3.0.1 does not support the use of the IBM SVC? We have an RPQ with IBM for SVC support (Special build of ESX 3.0.1 is required for SVC support).

DB

DB

View solution in original post

0 Kudos
40 Replies
sbeaver
Leadership
Leadership

I have seen this and I only rescan from the service console now using esxcfg-rescan vmhbaX for that reason

Steve Beaver
VMware Communities User Moderator
VMware vExpert 2009 - 2020
VMware NSX vExpert - 2019 - 2020
====
Co-Author of "VMware ESX Essentials in the Virtual Data Center"
(ISBN:1420070274) from Auerbach
Come check out my blog: [www.virtualizationpractice.com/blog|http://www.virtualizationpractice.com/blog/]
Come follow me on twitter http://www.twitter.com/sbeaver

**The Cloud is a journey, not a project.**
boydd
Champion
Champion

I agree with Steve - do it from the CLI (I've even seen this fail). What ESX build are you using?

DB

DB
VMdawg
Enthusiast
Enthusiast

Were using ESX 3.0.1 32039

0 Kudos
VMdawg
Enthusiast
Enthusiast

Does it help to remove the datastores from the host in VC before deleting the mappings through SVC?

0 Kudos
boydd
Champion
Champion

Yes and did you know that the standard build(s) of ESX 3.0.1 does not support the use of the IBM SVC? We have an RPQ with IBM for SVC support (Special build of ESX 3.0.1 is required for SVC support).

DB

DB
0 Kudos
VMdawg
Enthusiast
Enthusiast

I do now Smiley Wink

0 Kudos
Monoman
Enthusiast
Enthusiast

That is interesting about the SVC. It is funny that our IBM folks never mentioned that to us when they were selling us a VMWare solution.

I have seen the HBA scan issue. It seems to help if you delete the datastore in VC first.

0 Kudos
VMdawg
Enthusiast
Enthusiast

I tested removing the datastore on the host through VC first, then I deleted the vdisk to host mappings and rescanned the HBA's but it still timed out. Looks like rescanning directly from ESX or getting the "special" ESX-SVC build is the only option...

0 Kudos
Monoman
Enthusiast
Enthusiast

I would like to hear if an SVC specific build or patch is released.

0 Kudos
Lfrisino
Enthusiast
Enthusiast

We used to experience a similiar issue. This was resolved via the Forum and VMware. What we now do when we rescan for the HBAs under Storage Adapters, we uncheck one of the two (Scan for New Storage Devices, and Scan for New VMFS Volumes) and rescan each one at a time. We also changed the 'Disk.Max.Lun' setting under Advanced Settings>Disk. We found out that VC timed out when scanning for 256 luns. VMWare recommended changing it to 25 (we changed ours to 30).

0 Kudos
VMdawg
Enthusiast
Enthusiast

I have tried rescanning one at a time in the past and it seems to not lock up as you suggested...I'm also going to try changing the Disk.Max.Lun to 30 as well. Thanks for your suggestions!

0 Kudos
VMdawg
Enthusiast
Enthusiast

FYI- I changed Disk.Max.Lun to 30 and rescanned (new storage/VMFS) one at a time and it still timed out. I'm going to try getting my ESX levels up to date and check into that special ESX build for SVC...

0 Kudos
VMdawg
Enthusiast
Enthusiast

Host still timing-out when rescanning HBA's. Working on a special ESX build with IBM, but would still like to know other solutions...

0 Kudos
boydd
Champion
Champion

The build that we got via our RPQ with IBM was ESX 3.01 36662. Even with this specific build - it is better to use "esxcfg-rescan" from the cli. To list the luns/paths use "esxcfg-mpath -l | more". Also - make sure to only use 4 paths per lun/vdisk vs. the default of 8. I wish IBM would hurry up here and get their stuff certified for ESX 3.x.

DB

DB
0 Kudos
VMdawg
Enthusiast
Enthusiast

I just got off the phone with IBM and they're saying VM will be releasing an ESX version in June 07 that deals specifically with SVC compatibility etc. I was asking them about their special ESX build, and I'm not sure if it will even address the bug's I'm seeing. I think I'm just gonna wait it out and see what VM comes up with to address SVC.

0 Kudos
boydd
Champion
Champion

ESX 3.0.2 will have SVC cert. Also verify that you are not using "mru" (Need to be using "fixed" pathing). run "esxcfg-mpath -l " to see and run "esxcfg-mpath --policy=fixed --lun=vmhba#" to change.

DB

DB
0 Kudos
VMdawg
Enthusiast
Enthusiast

I called IBM the other day and apparently VMware is releasing a new version of ESX which supports SVC. IBM said it would be out in June07, my reseller says October07...either way I'm waiting for VMware's build because if you install IBM's you can update with VMware patches.

Message was edited by:

VMdawg

0 Kudos
MBrownHenn
Contributor
Contributor

Our IBM SAN rep tells us that VMware and IBM are meeting today 5/17/07 to discuss this issue.

Un-officially:

Our VMware corporate technical rep informed us that VMware will not support any RPQ from IBM. If we choose to go with SVC we will need to rebuild all our ESX 3.0.1 servers using the IBM version of ESX and receive 100% of our support from IBM. Having a proprietary OS from a company that did not design it sounds like a terrible idea to me.

Another observation from the VMware tech was that very few of their customers by percentage actually use SVC and that they cannot rebuild their OS to accommodate them. The main reason they can't configure ESX to work with SVC is because IBM will not share the code, so it becomes a bottom-line money issue.

We are considering our options, including getting rid of SVC for our ESX servers and dedicating storage to these systems that is not managed by SVC, which would mean no more site-to-site mirroring of LUN's that host our VM's.

Another option will be to look for another virtualization solution, but nothing can touch ESX and I think VMware knows it and likes it that way.

0 Kudos
Eric1h
VMware Employee
VMware Employee

Let me address the above statements. I am the VMware Alliance Engineer for VMware, I manage the relationship between VMware and IBM for Storage.

VMware will not support any RPQ from IBM - this is blatantly incorrect. Once the RPQ is submitted and Approved, IBM AND VMWare will fully support the solution.

If we choose to go with SVC we will need to rebuild all our ESX 3.0.1 servers using the IBM version of ESX and receive 100% of our support from IBM. Having a proprietary OS from a company that did not design it sounds like a terrible idea to me. - Again incorrect. IBM did not build the "special version of ESX to fit the needs of their SVC. The code is and always has been, and will continue to be written by VMware Engineers. You are correct in that there were code issues getting SVC to work in the "off the shelf" versions of ESX, so we(VMware) worked diligently with IBM to fix both the code on their end, and on ours. Because of the code issues and limited testing we had initially done we opted to enable support via an IBM RPQ to support the GOS's and Hardware configs we know worked. The driver behind this was, just the opposite of what was stated above. The SVC has a huge install base, and we wanted to enable customers to get at least limited support for the solution until further certification could be done. We will have full support for the SVC in the code release tentively slated(as always with software) for later this year. Until then, you will need to continue use the "special code" build of ESX.

The SVC was and is the only Storage virtualization we currently support today.

Message was edited by:

Eric1h

0 Kudos