Le 21/12/2015 22:51, Steinmetz, Paul a écrit :
(I prefer Marc, ;-) )

Very powerful stuff, isn't it.
Combination of virtual disks and STRASPBAL .
For the actual disks, you still need to IPL to DST to stop Raid.
No raid on virtuals, so no need to stop Raid here.
Did something change here with V7R2?

I am using external storage on DS8xxxx not internal storage. The disk protection is provided by the Disk Storage system, not an internal controller. IBM i is not aware of the real protection. It will see the volumes as Raid5 protected or not, according to the volume configuration (Protected or Un-Protected), whatever the real disks protection which can be Raid5, Raid10 or Raid6. When I write "format to Raid5", this is an operation at the DS level on disks which are no longer used at all by any partition.

I've done this process twice now over the last 10 years.
2007 - migrated 35 and 70 to all 144 spinny, very slow because the CEC controller was involved.
2015 - migrated 177 SSD to 775 SSD, extremely fast.


-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Marc Rauzier
Sent: Monday, December 21, 2015 4:39 PM
To: midrange-l@xxxxxxxxxxxx
Subject: Re: Another use for virtual disks, migration to new disks

Le 21/12/2015 22:06, Steinmetz, Paul a écrit :
I've thought of another use for virtual disks, curious if anyone has done this.
You need to swap out your current disks with larger ones, but no available disk slots for the new disks.
Restoring the system is not an option, too much down time.

Create some virtual disks on another LPAR, move the data using STRASPBAL.
You could then remove some of your disks, add new larger ones.
Move both remaining data and data from previous virtuals disks using STRASPBAL.
Remove remaining disks, add new larger ones.

Save load source for last, SST copy load source utility booting to DST.

I've done a similar process, but I had empty slots for the new disks.

Any thoughts from the group?
We are doing the same kind of operation, which is made easier with virtual adapters, not disks. But the principles are the same.

We have one partition with around 10 TB of external storage using 35GB volumes on Raid10 protected disks in a DS8300. This partition needs more and more space, and we start to be close to the end of available capacity on our external storage systems.
So we decided to move those 10TB to external 70GB volumes (which does not change a lot comparing to 35GB volumes) on Raid5 protected disks.
And, in order to keep the same performance level, we are using around 1TB of 70GB volumes on an SSD array in a DS8700.
The plan is to allocate new 70GB Raid5 volumes, stop allocation on existing 35GB Raid10 volumes, move the data from the old to the new volumes. We keep an eye on the performance to be able to move hot data to 70GB SSD volumes, with STRASPBAL command. As we are running 7.1 we can remove the volumes from the configuration without an IPL, using SST.
When the Raid10 arrays are empty, we can then format them to Raid5 so that we can restart the cycle until the needed capacity will use 70GB
Raid5 volumes.

The load source will be managed later, through DST Copy Disk option, with an IPL which is possible most of the sundays on this partition.

Thank You
Paul Steinmetz
IBM i Systems Administrator
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 thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2020 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].