|
Nope... Running the drives off the internal 5709 on the 520. The reason I stopped raid is that the new raid cards use a different stripe pattern. Then system will convert on the the fly to the new format, but I wanted to control when that happened. The real point was that I was able to take "ALL" the configured DASD in my case and plug them in to the new system and IPL. I didn't need to do a loadsource migration or an restore beacause I was able to bring all 8 of by 17gb 10K drives over. _____________________ Kirk Goins CCNA Systems Engineer, Manage Inc. IBM Certified iSeries Solutions Expert IBM Certified iSeries e-Business Infrastructure IBM Certified Designing IBM e-business Solutions Office 503-353-1721 x106 Cell 503-577-9519 kirkg@xxxxxxxxxxxxx www.manageinc.com There are 10 types of people in the world: Those that understand binary, and those that don't. Philipp Rusch <philipp.rusch@xxxxxxxxxxxx> Sent by: midrange-l-bounces@xxxxxxxxxxxx 10/22/2004 07:48 AM Please respond to Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx> To Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx> cc Subject Re: Cutover from 820 to i5/520 But Kirk, you did not move your "old" RAID controller, did you ? Mike, I doubt that a 2748 will work in a 520, besides you have to have another system frame (0595) for the number of disks you are moving. The main system frame holds only up to 8 disks which are controlled by the internal controller. HTH, Philipp kirkg@xxxxxxxxxxxxx schrieb: >I did something similar a couple weekends ago. #1 upgraded 820 5.2 TO 5.3 >#2 During the week I used the functions in STRASPBAL to move data off >several drives not migrating. >Next weekend >#3 Full System backup >#4 Did Final remove of disks not migrating (5 minutes) >#5 Broke RAID on remaining 8 drives >#6 Powered Down >#7 Moved all 8 drives to 520 making sure LS was in thr right spot >#8 IPL'd to DST verified HW etc >#9 Rebuilt raid >#10 IPL'd the OS >#11 Fixed resources >#12 Verified PTFs by running CUME and Groups thru... (NONE NEEDED TO BE >INSTALLED) >#13 Did a Fulll System Backup and let users on... >_____________________ >Kirk Goins CCNA >Systems Engineer, Manage Inc. >IBM Certified iSeries Solutions Expert >IBM Certified iSeries e-Business Infrastructure >IBM Certified Designing IBM e-business Solutions >Office 503-353-1721 x106 Cell 503-577-9519 >kirkg@xxxxxxxxxxxxx www.manageinc.com > >There are 10 types of people in the world: >Those that understand binary, and those that don't. > > > >"Condon, Mike" <M1C@xxxxxxxxxxxxxxxxx> >Sent by: midrange-l-bounces@xxxxxxxxxxxx >10/21/2004 06:49 PM >Please respond to >Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx> > > >To >"'Midrange Systems Technical Discussion'" <midrange-l@xxxxxxxxxxxx> >cc > >Subject >Cutover from 820 to i5/520 > > > > > > >We are going forward with a cutover from our current 9406/820 (p30) to a >new >i5/520 (p10) this weekend, or if logistics don't permit, on the 30th. All >is >ready on the 820 side - we just upgraded it from v4r5 to v5r3 and it's all >stable. >It's an upgrade moving the serial number over from the 820. We're keeping >the following, which will be transplanted from the 820 to the i5: >- Twinax Console card (2843-001) >- ECS card (2745-001) >- 10/100 Ethernet (2838-001) >- RAID Controller (284C-001/2748-001/268C-001/6B02-001) >- 10 disks from our current ASP/RAID set (Type 6717 Size 7516gb) > >So the procedure looks to be: >1. Two full system saves. >2. Break raid set. >3. pwrdwnsys. >4. Move the Twinax Console card, ECS card, Ethernet, RAID controller. >5. Move the current drives to the new "cans". >6. Power up i5 and........... > - OS is loaded intact from current ASP devices > - Follow standard Restore procedures >7. Cleanup work with licensed programs, network, ECS testing, etc. > >The issue with step #5/6 is that both our reseller and our IBM CE's are >not >certain that we can just move the disks and load the operating system from >our current load disk (from position 02 on the new 520) and the rest of >the >ASP, and then add the new disks (qty 4 15k rpm disks - don't know the >model >offhand) & reconfig the raid set. The other option is to move all of the >gear and then perform the standard restore procedures. >Regardless, we'll have to deal with Console/ECS/Network. >So I'm not getting a real warm feeling about how uncertain they are about >how this will pan out. I'm prepared for either scenario, but would of >course >like to load from our disks in place since our users will see the new >machine much sooner. >If any of you from experience can let me know how this will more than >likely > >turn out, I'd really appreciate it. In the past couple of weeks, it went >from "yes, we can load from the current disks" to "maybe/not sure" to >"no", >then back to yes, and now it's "we'll just have to install them & see what >happen". >On a side note, we will end up with three network ports - (1) 10/100 >(2838-001 from the old machine), (1) 10/100 onboard, and one 10/100/1000 >onboard. >Is there a way to trunk all three together on the same IP address with >failover & load balancing? I have all three interfaces going to separate >switches to cover that point of failure. >-- >This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing >list >To post a message email: MIDRANGE-L@xxxxxxxxxxxx >To subscribe, unsubscribe, or change list options, >visit: http://lists.midrange.com/mailman/listinfo/midrange-l >or email: MIDRANGE-L-request@xxxxxxxxxxxx >Before posting, please take a moment to review the archives >at http://archive.midrange.com/midrange-l. > > >-- >This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list >To post a message email: MIDRANGE-L@xxxxxxxxxxxx >To subscribe, unsubscribe, or change list options, >visit: http://lists.midrange.com/mailman/listinfo/midrange-l >or email: MIDRANGE-L-request@xxxxxxxxxxxx >Before posting, please take a moment to review the archives >at http://archive.midrange.com/midrange-l. > > > > -- This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options, visit: http://lists.midrange.com/mailman/listinfo/midrange-l or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a moment to review the archives at http://archive.midrange.com/midrange-l.
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.