04-27-2012 06:40 AM
I have 5 Itanium RX6600, OpenVMS 8.3.1-H1 servers, which I need to migrate from EVA storage to IBM v7000
There does not seem to be much information available either on IBM site , HP or Qlogic
I wondered if anyone has had any experience of anything similar. and provide me with some much needed help
I guess I would need to upgrade EFI and HBA firmware, and also VMS patches Fibre Scsi 10 and Update 11
I have download and currently burning ISO of Offline Diagnostics Environment tools , in the hope that I can use it to upgrade HBA firmware
Also I have downloaded HP-I64VMS-OSIFM_RX3600_RX6600-V0415-A-1.ZIPEXE, I'm not sure how this fits with the rest of the updates/firmware
Any advice would be very appreciated
Current firmware revisions
MP FW : F.02.23
BMC FW : 05.24
EFI FW : ROM A 07.14, ROM B 07.14
System FW : ROM A 04.11, ROM B 04.11, Boot ROM A
PDH FW : 50.07
DHPC FW : 01.23
UCIO FW : 03.0b
PRS FW : 00.08 UpSeqRev: 0c, DownSeqRev: 08
HFC FW : 00.03 SetRev: 00
HBA firmware, as seen from VMS SDA FC
Device ......... FGA0:, PCI, Device ID 2422, Rev 03, QLogic ISP2422
Firmware V 04.00.5A
04-27-2012 10:50 AM
Paul, it isn't a big surprise that you're not finding much info about OpenVMS coupled with IBM storage. Generally speaking I'd want to be using the latest firmware and OpenVMS patch/update kits I had available but the STORAGE has to meet certain requirements for OpenVMS to be able to use it. Is the IBM v7000 storage definitely SAN-based? If so you're a step ahead but you'll have to find out if their storage can present a device ID to OpenVMS. You also probably want to creatively zone your system and the storage so that VMS doesn't "see" other storage or systems.
Please keep in mind that it is probably very unlikely that HP and/or OpenVMS engineering have already tested this configuration at all. I'd also guess that it wasn't on IBM's list of testing either. Nevertheless I'd go back to IBM and check with them for specifics about using their storage with OpenVMS on Integrity. Most of the requirements that OpenVMS needs are in the SAN specifications but, no offense intended to any particular vendor, not all of them see the need to provide everything that OpenVMS requires. So you might, hopefully unlikely, find out that it won't work and that you'd have to take up with IBM.
04-28-2012 02:59 AM
Hi Bob, thanks for your reply
Yes I believe th V7000 is qualified with OpenVMS, but most of the doc on the IBM site is regarding Alphaserver and not Integrity
The V7000 is SAN based. So I'm unsure about this HP-I64VMS-OSIFM_RX3600_RX6600-V0415-A-1.ZIPEXE, any ideas , as this looks to be VMS level not EFI update.
Also am I correct in saying the ODE is the correct method of updating Integrity HBA firmware?
04-28-2012 04:30 AM
As for the details of that HP-I64VMS-OSIFM_RX3600_RX6600-V0415-A-1.ZIPEXE file, that's a zip archve. You can either use unzip to extract it, or you can RUN it to use the OpenVMS I64 self-extraction, and it should produce a PCSI kit. Then use PCSI to extract the release notes or potentially to extract and look at other text files that might be within the kit, and if those files do not make sense, then look at the other files in the kit (and particularly any DCL) to see what it's doing.
A Bing search for "HP-I64VMS-OSIFM_RX3600_RX6600" finds rx3600 and rx6600 System, BMC, and iLO2 MP Firmware web page. That web page has some details on the update; that updates at least two of the three low-level consoles within that series of server.
In all seriousness and without intending any offense, if a zipped PCSI kit and a web search for details of the zipped PCSI kit have you stymied, please seriously consider what your chances might be with any issues that might arise within a mixed-environment third-party SAN integration. You're headed for the proverbial deep end of the pool, and I can infer you're not particularly familiar with OpenVMS and Integrity server management. As you proceed with this quest, you're going to get to map different requirements and different SAN terminologies (vendors can and do use different names for SAN settings), and quite possibly rummage through some rather confusing documentation for different sets of controllers and different host systems, particularly if the IBM documentation does not contain the details of setting up their controllers with VMS. Even if the IBM documentation does have all of the details of establishing AlphaServer configurations, then you'll minimally be replacing all the SRM details with EFI console commands.
Kick this up to your management, and have them sort this out; they've decided to require this integration, and it's now time for them to pay for that effort. For the fastest and least disruptive way to get this VMS box online with this V7000 SAN controller, it'll probably involve help from either HP or IBM support folks.
04-28-2012 07:51 AM
Thanks for your reply Hoff.
The zipped PCSI kit did not exactly have me stimied, I have worked with VMS for 25 years, with many of these as a system manager on VAX, Alpha and Integrity, but with regard to the low level console updates (HP-I64VMS-OSIFM_RX3600_RX6600), I thought these updates were done at EFI level and not host OS. The reason I originally posted was to ensure I was on the right track, and to see if anyone else had already implemented a similar migration. I will be contacting HP/IBM via our support contracts with regard to the details of this work.
Thanks for your input
05-01-2012 11:01 AM
We migrated from an EVA 4400 to an IBM v7000 a year ago (4 Integrity blades running OpenVMS 8.4).
Due to performance issues we migrated back to an HP EVA this year.
IBM couldn't resolve the performance issues and we discovered that the HP EVAs do replication better for DR purposes.
05-02-2012 02:18 AM
Hi Chris, many thanks for your reply.
Do you think you give me some more details of this issue or the IBM Ticket number, so we can look into this?
05-02-2012 08:00 PM
I'm replying with Chris on this, we work for the same place.
There is no ticket associated with it, it's a matter of experienced limitations that pulled us off of it and put us on an EVA6500 pair.
For us, the V7000 was so new, it was never tested with VMS in general. Yes LUNS were present, and yes we could read and write to it, but the replication was not very well done. In general, replication on a V7000 is "live", there is no cache.
If you lose the link between the V7000's, even for a moment, replication stops...dead...it does not start automatically afterward. We used a script that just stopped and restarted replication every hour because we never knew the state of it and didn't want emails everytime it stopped for some reason (RTT Delay, excessive writes, line jitter, or a momentary drop in the line). We also could not run replication during peak usage hours because it slowed everything down tremendously.
The latest version of the V7000 firmware does allow for "better" replication, as it allows for a set of disks for a snap copy, and uses those disks to replicate. Think of this as shadowing if you are not familar with it, but the shadowing takes places in snapshots. So if you have 10tb of disk, you need 20tb on the host side for this snapshot capability if you snap the whole set.
In my mind, I am not sure why a V7000 is the answer for you. The EVA's are so much better, they can sustain themselves through jitter, increased RTT, and line outages (they just log, the V7000's need to do a bit by bit comparison of the two sides, and then recopy the disk if it is too far out of sync). The logging on the EVA's is limited to a set amount of disk space, and we have taken 7 hour outages (to date) on our link from hither to yon, and the logging catches up very quickly.
In essence, the VMS option for the V7000 was an "afterthought" to pick up more market by IBM (my opinion), but the design is not suited for our use. Your mileage may vary here.
If you have the option, and have not committed, you may want to reconsider. Of the storage devices I have seen, I would pick EVA's over the V7000s.
If you did commit and implement them, please let us know how it goes, and how they operate long term for you.
05-02-2012 08:10 PM
In reply to Hoff's message, I will also tell you that there are very firm, strickt and rigid guidelines on how your SAN Fabric is configured. Routers, settings and configurations must also be considered. If ou have one setting out of wack, or do not follow the vendor's specific guidelines then they will not support you until you fix it. Being in a mixed environment (HP and IBM) the guidelines will vary wildly, throw in your routers/SAN Fabric and their specifications and you'll pull your hair out trying to figure out how to set things up in a vendor best practice situation.
If you're using FCIP tunnels it get's even more confusing and you have far more to configure.
And as I have found, the IBM interfaces to the V7000 are not very friendly.
The EVA's make it easy with the Command View interface, and it is much more flexible.
When you put this together with a possible lack of knowledge on the Integrity Server management, and you may just have issues finding your boot disk (this can be a totally frustrating experience)!
By the way, how are you migrating from one to the other?
05-03-2012 03:43 AM
Hi Mike, many thanks for your reply.
Our EVA models are at end of life soon, and will be moving off VMS platform soon too, so I have been charged with setting up some testing for Integrity, OpenVMS and V7000. We do not use replication, but use Host based volume shadowing.
With regard to HBA firmware upgrades, did you also have to update EFI/MP/ILO Firmware ?
05-03-2012 03:56 AM
I will not be involved with that detail of the configuration/migration, but the SAN Team. I will just be involved in the VMS side.
I believe that the SAN team said that we will using somes ort of transition process, where the v7000 can present the EVA storage.
05-03-2012 05:50 AM - edited 05-03-2012 05:56 AM
EFI firmware? Sure. Upgrade the firmware. That probably won't hurt. That might or might not help, either.
It's within the realm of possibilities that certain SAN controllers will require certain firmware versions or specific ranges of firmware versions (either due to bugs or due to what's been tested and thus considered supported), and upgrades or (potentially) firmware downgrades might be required. Again, this is deep into the quagmire of multi-vendor SAN support and mapping different host operating systems and versions and different HBAs and different SAN controllers and different firmware, and all the complexity that arise from all these pieces. Firmware is just one part of this morass.
(To give you a flavor of the complexity here, there's another thread going here in the VMS HPSC whatever-Lithium-calls-it section with some folks that are having issues with unexplained and large SAN controller latency variations, and that's within a single-vendor solution.)
If your local IT is stove-piped (and as often happens in larger entities), then these projects get even more complex, as this troubleshooting crosses hardware and software and firmware and SAN and device and networking, and that can lead to a cast of folks and internal support centers and external support centers and out-sourced help desks and...
What may be the least disruptive is an EVA lease. Whether that's cheapest depends on whether the platform migration occurs on schedule.
While this matter involves a variety of technical issues, it's also most definitely a management issue and management decision. I'd lease an EVA or look for a recent used EVA, or see about bringing in some help. And that might still end up leasing or a gently-used an EVA.
If there are any SAN vendor representatives reading here, SAN storage user interfaces are ripe - RIPE - for disruption. The SAN-related user interfaces on every device I've encountered can most charitably be referred to as weak. With a better UI and easier or even transparent management and a commensurate push into higher volumes, somebody's going to make a whole lot of money. And everybody else in the SAN market (and service revenues) will get marginalized.
05-04-2012 06:02 AM
Hoff, Thanks again for your informative response.
Unfortunately due to our circumstances here, we do not have another option. They will not even think about leasing/buying a newish EVA pair, as VMS will be gone from this site in 6-9 months.
However, using your information and the info from the other replies to this post, I will raise it as a risk.
Update the HBA firmware , and associated Fibre scsi and update VMS patches on a test box, and stress test it and see what happens.
05-05-2012 03:49 PM - edited 05-05-2012 03:52 PM
>there's another thread going here in the VMS HPSC whatever-Lithium-calls-it section
It would be more helpful if you included a link.
(This is the EBC forum, not HPSC and they are called categories and under them, boards. :-)