My question here is that 59 out of 195 volumes in the pool are less than 75% 
utilized.
Shouldn't tsm fil them before declaring itself out of space?

-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of 
David Ehresman
Sent: Monday, June 08, 2015 12:07 PM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: [ADSM-L] server out of storage space when really not missing 
vmware backups

Maxscratch defines how many scratch volumes you can have in a storagepool.  
When you reach maxscratch, assuming you do not have volumes predefined, you are 
by definition out of data storage space regardless of how much space is in your 
filesystem.


-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of 
Lee, Gary
Sent: Monday, June 08, 2015 10:32 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: [ADSM-L] server out of storage space when really not missing vmware 
backups

Tsm server 6.2.5
TDP for vmware 6.4

I have the vmware data pool defined as a sequencial file pool, to facilitate 
migration.

However, last night the server claimed it was out of data storage space, but 
there is 18% of a 14 tb pool free.

I checked, and the only limit reached was maxscratch.

Is there a good way around this?

We want to migrate to server 7.x, but could not get an install failure resolved 
on RHEL 6.5 for server version 7.1.1.

I have increased maxscratch, but this cannot go on indefinitely.