The only oddity I see is that DDSTGPOOL4500 has a NEXTSTGPOOL of TAPEPOOL.
Shouldn't cause any problems now since utilization is 0% but would get
triggered once you hit the HIGHMIG threshold.
Is there anything in the activity log for the errant migration processes?
On Wed, Sep 21, 2016 at 03:28:53PM +0000, Plair, Ricky wrote:
> OLD STORAGE POOL
>
> tsm: PROD-TSM01-VM>q stg ddstgpool f=d
>
> Storage Pool Name: DDSTGPOOL
> Storage Pool Type: Primary
> Device Class Name: DDFILE
> Estimated Capacity: 402,224 G
> Space Trigger Util: 69.4
> Pct Util: 70.4
> Pct Migr: 70.4
> Pct Logical: 95.9
> High Mig Pct: 100
> Low Mig Pct: 95
> Migration Delay: 0
> Migration Continue: Yes
> Migration Processes: 26
> Reclamation Processes: 10
> Next Storage Pool: DDSTGPOOL4500
> Reclaim Storage Pool:
> Maximum Size Threshold: No Limit
> Access: Read/Write
> Description:
> Overflow Location:
> Cache Migrated Files?:
> Collocate?: No
> Reclamation Threshold: 70
> Offsite Reclamation Limit:
> Maximum Scratch Volumes Allowed: 3,000
> Number of Scratch Volumes Used: 2,947
> Delay Period for Volume Reuse: 0 Day(s)
> Migration in Progress?: No
> Amount Migrated (MB): 0.00
> Elapsed Migration Time (seconds): 4,560
> Reclamation in Progress?: Yes
> Last Update by (administrator): RPLAIR
> Last Update Date/Time: 09/21/2016 09:05:51
> Storage Pool Data Format: Native
> Copy Storage Pool(s):
> Active Data Pool(s):
> Continue Copy on Error?: Yes
> CRC Data: No
> Reclamation Type: Threshold
> Overwrite Data when Deleted:
> Deduplicate Data?: No
> Processes For Identifying Duplicates:
> Duplicate Data Not Stored:
> Auto-copy Mode: Client
> Contains Data Deduplicated by Client?: No
>
>
>
> NEW STORAGE POOL
>
> tsm: PROD-TSM01-VM>q stg ddstgpool4500 f=d
>
> Storage Pool Name: DDSTGPOOL4500
> Storage Pool Type: Primary
> Device Class Name: DDFILE1
> Estimated Capacity: 437,159 G
> Space Trigger Util: 21.4
> Pct Util: 6.7
> Pct Migr: 6.7
> Pct Logical: 100.0
> High Mig Pct: 90
> Low Mig Pct: 70
> Migration Delay: 0
> Migration Continue: Yes
> Migration Processes: 1
> Reclamation Processes: 1
> Next Storage Pool: TAPEPOOL
> Reclaim Storage Pool:
> Maximum Size Threshold: No Limit
> Access: Read/Write
> Description:
> Overflow Location:
> Cache Migrated Files?:
> Collocate?: No
> Reclamation Threshold: 70
> Offsite Reclamation Limit:
> Maximum Scratch Volumes Allowed: 3,000
> Number of Scratch Volumes Used: 0
> Delay Period for Volume Reuse: 0 Day(s)
> Migration in Progress?: No
> Amount Migrated (MB): 0.00
> Elapsed Migration Time (seconds): 0
> Reclamation in Progress?: No
> Last Update by (administrator): RPLAIR
> Last Update Date/Time: 09/21/2016 08:38:58
> Storage Pool Data Format: Native
> Copy Storage Pool(s):
> Active Data Pool(s):
> Continue Copy on Error?: Yes
> CRC Data: No
> Reclamation Type: Threshold
> Overwrite Data when Deleted:
> Deduplicate Data?: No
> Processes For Identifying Duplicates:
> Duplicate Data Not Stored:
> Auto-copy Mode: Client
> Contains Data Deduplicated by Client?: No
>
>
> -----Original Message-----
> From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf
> Of Skylar Thompson
> Sent: Wednesday, September 21, 2016 11:19 AM
> To: ADSM-L AT VM.MARIST DOT EDU
> Subject: Re: [ADSM-L] TSM Migration Question
>
> Can you post the output of "Q STG F=D" for each of those pools?
>
> On Wed, Sep 21, 2016 at 02:33:42PM +0000, Plair, Ricky wrote:
> > Within TSM I am migrating an old storage pool on a DD4200 to a new storage
> > pool on a DD4500.
> >
> > First of all, it worked fine yesterday.
> >
> > The nextpool is correct and migration is hi=0 lo=0 and using 25 migration
> > process, but I had to stop it.
> >
> > Now when I restart it the migration process it is migrating to the old
> > storage volumes instead of the new storage volumes. Basically it's just
> > migrating from one disk volume inside the ddstgpool to another disk volume
> > in the ddstgpool.
> >
> > It is not using the next pool parameter, has anyone seen this problem
> > before?
> >
> > I appreciate the help.
>
> --
> -- Skylar Thompson (skylar2 AT u.washington DOT edu)
> -- Genome Sciences Department, System Administrator
> -- Foege Building S046, (206)-685-7354
> -- University of Washington School of Medicine
>
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> CONFIDENTIALITY NOTICE: This email message, including any attachments, is for
> the sole use of the intended recipient(s) and may contain confidential and
> privileged information and/or Protected Health Information (PHI) subject to
> protection under the law, including the Health Insurance Portability and
> Accountability Act of 1996, as amended (HIPAA). If you are not the intended
> recipient or the person responsible for delivering the email to the intended
> recipient, be advised that you have received this email in error and that any
> use, disclosure, distribution, forwarding, printing, or copying of this email
> is strictly prohibited. If you have received this email in error, please
> notify the sender immediately and destroy all copies of the original message.
--
-- Skylar Thompson (skylar2 AT u.washington DOT edu)
-- Genome Sciences Department, System Administrator
-- Foege Building S046, (206)-685-7354
-- University of Washington School of Medicine
|
