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?
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
I have seen this and I only rescan from the service console now using esxcfg-rescan vmhbaX for that reason
I agree with Steve - do it from the CLI (I've even seen this fail). What ESX build are you using?
DB
Were using ESX 3.0.1 32039
Does it help to remove the datastores from the host in VC before deleting the mappings through SVC?
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
I do now
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.
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...
I would like to hear if an SVC specific build or patch is released.
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).
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!
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...
Host still timing-out when rescanning HBA's. Working on a special ESX build with IBM, but would still like to know other solutions...
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
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.
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
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
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.
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