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@VM.MARIST.EDU] On Behalf Of > Skylar Thompson > Sent: Wednesday, September 21, 2016 11:19 AM > To: ADSM-L@VM.MARIST.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 (skyl...@u.washington.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 (skyl...@u.washington.edu) -- Genome Sciences Department, System Administrator -- Foege Building S046, (206)-685-7354 -- University of Washington School of Medicine
