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?
Thank you for clarifying this. It is hard to know what to believe any more, since we are getting two clearly different communications from both IBM and VMware on this. In private phone and in person conversations I hear one thing and in public settings like this forum I here another.
If I was making this up, spreading hearsay or guessing at what I thought VMWare and IBM were saying, I would stand corrected. Clearly both companies need to improve their communication on this matter to the vast[/u] SVC customer base.
I'm glad the VMware tech was wrong on this and it's very encouraging to hear that 3.1 will fully support SVC.
I do not want to argue, but why would both a VMware technician from corporate (not from the help desk) and IBM technician tell us in person that VMware will not support the RPQ code configuration using IBM SVC? IBM will support "their build", but not VMware. We have already experienced third party support from HP, which is another story. We want support from VMware, not IBM.
I'll be waiting for something official from both companies before proceeding.
directly from one of our internal documents that was sent world wide to every Sales and field SE.
3. If the RPQ is approved, the customer will receive a special build from VMware and support for the build from IBM and should contact the IBM Support Center directly (even if the customer typically receives support from VMware). IBM will escalate to VMware as needed. Standard rules for the RPQ (e.g. once a GA release is available, the customer will need to move to it) will apply.
So, yes, the initial support will come from IBM, per the contract/agreement stated in the RPQ. But VMware will still support the configuration and take all escalations, but the initial call will need to be made to IBM. However, I can say this(because we track this sort of information) There has never been a need for a level 3 escalation of an SVC/VMware issue to date.
But again, the code came from us, not something IBM wrote/added to.
I would go ahead and get your IBM rep to submit the RPQ, its takes little more than a phone call to get the process started, once you apply for the RPQ, you will get the terms and rules of the RPQ to see the "official statement"
Message was edited by:
My environment consists of over 150 VM's on 25 hosts. Why would I want to go to the trouble of staging everything to upgrade my hosts to the IBM build if VMware is releasing a new build this year to address SVC. If I install IBM's build I cannot install any official VMware patches, so I'm stuck with IBM's build until Novemeber or whenever VM's build comes out. It just doesn't make sense to invest that kind of time and resource in the long run.
This is great! I have a prime example of the double-speak coming from VMware on this issue. Eric1h, you claim to be a VMware employee. Could you check the source on this?
From our VMware rep (I will withhold names, for now) at 2:27 CST today in reply to me asking what the status is of ESX/SVC supportability:
"[u]The VMware for SVC is distributed and supported by IBM only.[/u] No change in that is likely. It is so unique and needed only for SVC that it will probably not be incorporated into ESX. Best suggestion is to keep the spotlight on IBM for this."[/i]
I can only interpret from this that there is a separate distribution of ESX for SVC. I confirmed that on the phone with the VMware SE. I also interpret that if we go down this path, we are stuck in IBM support for the distant future because we have a proprietary install. Will IBM support a migrating to ESX 3.1 when it comes out with SVC support? Again, our VMware rep says that "It is so unique and needed only for SVC that it will probably not be incorporated into ESX".
There are always two options:
Option #1 - Do nothing
Option #2 - Do everything possible to make Option #1 the only option.
I am getting contradictory claims from VMware about them integrating support for SVC into ESX. Publicly (in the forum and via other alerts) VMware claims that support will be incorporated into ESX 3.1. 30 minutes ago a received an email from VMware that said ESX will likely never incorporate support for SVC in ESX.
VMdawg, we are in a very similar situation. We have not run into any problems with SVC specifically, but now we cannot call into support because of it. We went with HP's VMware support because all our hardware is HP (DL 585 G2's) to save $$. What a bad idea. Now we may have to call IBM for support if we choose to keep SVC for our virtualization environment. I can just imagine it now, "hello IBM support?, yeah, I'm running on HP servers and I need help...." IBM: "Sorry, we only support ESX using SVC on IBM servers". Doh!
VMware - I hope someone is scrambling around to clarify your communication on this.
We will likely wait a little while and then get rid of SVC in the virtual environment, forcing us to dedicate a multi-million dollar storage device to VI. There goes our site-to-site mirroring and FlashCopy that we get from SVC.
Here another thread with some good information:
Let's keep the pressure on VMware to push IBM to release RPQ's for SVC. So far, IBM will not approve an RPQ for us because we use Emulex HBA's. We would have to switch to QLogic to get an RPQ #. I understand that they can only approve one configuration at a time. Wait! Were talking about a multi-billion dollar company! They should be able to approve more than one config at a time.
I will not be happy if the only way I can be supported is through an RPQ from IBM that they won't issue. Even if they do, we are stuck in limbo until 3.1 is released.
With absolutely no uncertainty, future "off the shelf versions" of ESX WILL incorporate support for SVC, the RPQ process is temporary until full support is announced and testing is finished.
HennITLS, if you could PM me offline who your local rep and SE are so I can educate them on the status. Apparently, some people are misinterpreting the internal information that has been distributed.
And again to make it clear, the 36662 is a VMWARE build, not IBM, and actually the build simply incorporates some Qlogic driver fixes into ESX.
Those fixes have not yet been incorporated into the Emulex drivers, and the Emulex cards prove more challenging because we cannot load our firmware to the card at boot time like we do with the Qlogics, this has been a problem since we first started supporting Emulex cards. The RPQ support will eventually go away and you will get support from whomever you choose, VMWare or IBM. Until then we have to follow the RPQ process.
IBM agreed to support this from their end to offload the process from our support engineers for level 1 support and get support for their customer sooner.
Stay tuned full support is coming, but for obvious reasons we can't release dates.
Feel free to PM me offline you any of you would like more information, or if you have an RPQ that is "stuck" But I won't post my contact info on a public forum.
See my PM. Unfortunately we were at ESX 3.0.1 build 39823 when we found out about the RPQ requirement for support from IBM when using SVC. IBM has advised us to hold off on any further patches, which is wise, until they have tested a solution with Emulex adapters and can release an RPQ # for us. Rolling back to 36662 sounds like it would be a difficult process. I will post our progress.
I know, I know... we should have had a certified config in writing before building ESX 3.0.1 within our SVC environment. But then again, we would have no virtual environment since we were just starting out with 3.0.1. Funny that the VMware reps and SE's (not the same people that we have today) didn't mention this during the sales stage, hmmm. They knew our SVC config too.
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't update with
Message was edited by:
"if you install IBM's you CAN'T update with VMware patches"
We have our RPQ # now from IBM! We decided to swap out the Emulex HBA's for QLogic. Once that was decided we had the RPQ "faster that you can order a pizza", to quote the IBM rep.
One small problem, there is no information in the readme file or a document that tells you what to do next. I can only assume that we swap out the HBA's and do a complete reinstall of the ESX OS. Oh the pain!
Resistance is Futile ;-). I figure that the next time this happens IBM is going to test and approve QLogic again because of it's market share. We want to avoid the Emulex delay.
We will be dumping Emulex HBA's on all our future server purchases and going with Qlogic across the board (500+ servers). Sorry Emulex, you snooze, you lose. How does that saying go....?
"If we really care for the customer we'd send them somewhere better"
I have the download "SVC Build" 36662 burned to CD and I'm ready to go. I am grateful for the help and direction, I wish there was official VMware and IBM guidance after with the download! With no official word from them on how to proceed after getting our "Holy Grail" RPQ, I will be cautious. Email requests for such info are not getting a response.
We'll be experimenting on some test ESX servers before throwing it into prod.
Here is my first DRAFT of a plan, (without any guidance from either IBM or VMware):
We have three, 3 node clusters (9 hosts) that need the "downgrade" hosting 75 VM's per cluster.
1. I'll start by backing up critical config files on ESX Host#1 of Cluster #1
2. ??Disconnect from existing LUN's??
3. I will put Host#1 in Maintenance mode
4. I will remove Host#1 from the Cluster#1
5. Shut Down Host#1
6. Remove Emulex HBA's
7. Install QLogic HBA's
8. Boot up to the CD-ROM 36662 SVC build
9. See what happens, if it asks me to upgrade I will choose that option. If it is a complete reinstall that will blow away all settings, so be it.
11. Once the ESX OS is up, connect to the LUN's
12. Once the install is complete, Host#1 will be rejoined to Cluster#1 (I'm not sure if it will even be able to rejoin the cluster with the new QLogic HBA's until all the nodes in the cluster have the new HBA's.
13. Migrate VM's to this server.
14. Proceed to host#2 in cluster#1, and so on.
15. Enjoy Memorial Day weekend remembering our fallen heroes from the past and present.
I need to apologize for high-jacking your forum question. To try and compensate you, I will attempt to help you with the problem of the rescan of the HBA's. I may be off-base, because you said you were doing the rescan via the SVC rather than in VC. Perhaps you need to do a rescan in VC following the procedure below.
Here is a VMware article that could apply to your situation. The fix is in QA testing (Hmmm, I wonder if it will be released in June07?).
From an HP article:
VMware engineering is aware of the issue and is currently working towards a permanent solution. Until a permanent solution is available, rescan one HBA at a time either manually or using a script containing a rescan command line.
When performing a rescan from the Virtual Infrastructure Client, the Rescan dialog box is displayed. When the dialog box appears, perform the following steps to complete a full set of rescans:
1. Uncheck either one of the boxes.
2. Click on OK.
3. Initiate a second rescan.
4. Uncheck the other box.
5. Click on OK.
Do not perform a rescan with both boxes checked as this may cause the rescan or the service console to stop responding.
For additional workaround solutions, refer to VMware Knowledge Base Article 10229 at the following URL:
The VMware Knowledge Base Article will be updated when the permanent solution is available.
2. ??Disconnect from existing LUN's??
You should definitely do this...we have had absolutely no success leaving LUN's mapped when upgrading ESX...always gives us problems.
I'm actually re-scanning the storage through VC when it causes the lockups/timeouts
p.s. No prob on the hijack...