date:20180209

SnapDiff threading question

2018-02-09 Thread Schaub, Steve

We have 6 Netapp fileshares that have a small number of large files but TB 
daily change rates.
When Snapdiff runs, we are not seeing the number of sessions we expect after 
setting resourceutilization=10.
Is this due to how TSM is receiving the changed file list from the Netapp?
Would we be better off forcing CreateNewBase=yes on every run to increase 
multi-threading?
Thanks,
-steve



--
Please see the following link for the BlueCross BlueShield of Tennessee E-mail 
disclaimer:  http://www.bcbst.com/email_disclaimer.shtm

Re: Influencing order of VM backup.

2018-02-09 Thread Ryder, Michael S

You can take more control by setting up specific schedules to backup some
VMs first.  You might use VM folders to control that as well.

Do you let VMs backup in parallel with "VMMAXParallel" ?  It defaults to
1...

You can also have multiple jobs running simultaneously.  It's not clear to
me, are you using the "IBM Spectrum Protect for Virtual Environments: Data
Protection for VMware"?  If so, in addition you could be running multiple
jobs on multiple datamovers simultaneously.

Enabling #>1 on VMMAXParallel and multiple datamovers helped us to
drastically reduce our backup windows.

Best regards,

Mike

On Fri, Feb 9, 2018 at 6:08 AM, Marc Lanteigne 
wrote:

> Hi,
>
>  You could configure a new DataMover to handle that VM.
>
>  In the preview, is the order alphabetical?  If so, can you rename the VM?
>
>  Marc...
>
>  Sent from my iPhone using IBM Verse
>
>  On Feb 8, 2018, 11:17:20 PM, steven.har...@btfinancialgroup.com wrote:
>
>  From: steven.har...@btfinancialgroup.com
>  To: ADSM-L@VM.MARIST.EDU
>  Cc:
>  Date: Feb 8, 2018, 11:17:20 PM
>  Subject: [ADSM-L] Influencing order of VM backup.
>
>
>Hi All
>   Thanks for the input on my recent query about 7 Year VM backups.  I'll
> let you know when I decide something.
>   Moving on..
>   TSM Server  7.1.1.300 AIX,  Datamovers and Storage Agents on Redhat,
> writing to Protectier VTL, TSM for VE 7.1.1/2 hybrid.
>   We can't use the VMware plugin because of separation of duties concerns,
> so we edit the DOMAIN.VMFULL lines in the dsm.sys stanzas. VMs have a range
> of different sizes that all back up on the same schedule and we'd prefer
> not to split this up.  The execution order of the VM backups is determined
> by TSM for VE, somehow, and can be seen when a backup vm -preview is run.
>   There are some large VMs that take quite a while to back up, but
> unfortunately run late in the execution order, so we overrun our backup
> window.
>   Changing the order of the VMs in the DOMAIN.VMFULL statement does not
> influence execution order.  Is there any way to make the big ones run first?
>   Thanks
>   Steve
>   Steven Harris
>   TSM Admin/Consultant
>   Canberra Australia
>   This message and any attachment is confidential and may be privileged or
> otherwise protected from disclosure. You should immediately delete the
> message if you are not the intended recipient. If you have received this
> email by mistake please delete it from your system; you should not copy the
> message or disclose its content to anyone.
>   This electronic communication may contain general financial product
> advice but should not be relied upon or construed as a recommendation of
> any financial product. The information has been prepared without taking
> into account your objectives, financial situation or needs. You should
> consider the Product Disclosure Statement relating to the financial product
> and consult your financial adviser before making a decision about whether
> to acquire, hold or dispose of a financial product.
>   For further details on the financial product please go to
> https://urldefense.proofpoint.com/v2/url?u=http-3A__www.bt.
> com.au=DwIFAg=jf_iaSHvJObTbx-siA1ZOg=hMBqtRSV0jXgOdXEmlNk_-
> O9LHkPCGSh9PJBRSlL8Q4=DP7DwxCOv4YVWwNQ-mQuUUtEM6b1fb2rRkkXefrXlGA=
> aVJ5Y2IRgiGyROP9MaupUeZM6Y7X6bJW6eHIekbRugI=
>   Past performance is not a reliable indicator of future performance.
>
>

Re: No more client sessions after server upgrade.

2018-02-09 Thread Erwann SIMON

Hi all,

It seems that most of the answers can be found here : 
http://www-01.ibm.com/support/docview.wss?uid=swg22004844

-- 
Best regards / Cordialement / مع تحياتي
Erwann SIMON

- Mail original -
De: "Erwann SIMON" 
À: "ADSM: Dist Stor Manager" 
Envoyé: Vendredi 9 Février 2018 10:40:02
Objet: Re: [ADSM-L] No more client sessions after server upgrade.

Hi Eric,


The default certificate (indicated by a * on the left) on older version is 
MD5-signed. TLS 1.2 need a SHA-signed certificatee to be the default.
The update/upgrade process should change the default certificate but it seems 
that it does not.

Here are the commands to verify the default certificate and how to change it.

[root@centos7 config]# /usr/local/ibm/gsk8_64/bin/gsk8capicmd_64 -cert -list 
-db cert.kdb -stashed | tail -2
*-  "TSM Server SelfSigned Key"
-   "TSM Server SelfSigned SHA Key"

[root@centos7 config]# /usr/local/ibm/gsk8_64/bin/gsk8capicmd_64 -cert 
-setdefault -db cert.kdb -label "TSM Server SelfSigned SHA Key" -stashed

[root@centos7 config]# /usr/local/ibm/gsk8_64/bin/gsk8capicmd_64 -cert -list 
-db cert.kdb -stashed | tail -2
-   "TSM Server SelfSigned Key"
*-  "TSM Server SelfSigned SHA Key"

After server restart, the "old" MD5-signed certificate labeled "TSM Server 
SelfSigned Key" will be deleted.

PS : On Windows, path of gsk* commands is : C:\Program Files\Common 
Files\Tivoli\TSM\api64\gsk8\bin

I sometimes had to change the PATH : set PATH=C:\Program Files\Common 
Files\Tivoli\TSM\api64\gsk8\lib64:C:\Program Files\Common 
Files\Tivoli\TSM\api64\gsk8\bin:%PATH%

-- 
Best regards / Cordialement / مع تحياتي

Erwann SIMON

- Mail original -
De: "Eric van Loon (ITOPT3) - KLM" 
À: ADSM-L@VM.MARIST.EDU
Envoyé: Vendredi 9 Février 2018 09:39:58
Objet: Re: [ADSM-L] No more client sessions after server upgrade.

Hi guys,
To answer my own question so everybody else will be able to find it though 
ADSM-L. The solution was to generate a new certificate. During server startup I 
noticed the following message:

ANR3336W Default certificate labeled TSM Server SelfSigned Key in key data base 
is down level.

The fix was to stop the server and generate a new one by issuing the following 
command in the instance directory:

gsk8capicmd_64 -cert -setdefault -db cert.kdb -stashed -label "TSM Server 
SelfSigned SHA Key"

Afterwards all clients were working again.
Kind regards,
Eric van Loon
Air France/KLM Storage Engineering


On Mon, Feb 5, 2018 at 10:52 AM, Loon, Eric van (ITOPT3) - KLM < 
eric-van.l...@klm.com> wrote:

> Hi guys!
>
> I just upgraded our engineering server from 7.1.7 to 7.1.8 and clients 
> cannot connect anymore. The only session that is working is the one 
> from the server itself. I opened an admin console through it and when 
> I try to establish and admins session from my pc, it's rejected with 
> the message "ANR8599W The connection with :37404 failed 
> due to an untrusted server certificate. An attempt to reconnect and 
> establish certificate trust might follow." A backup session from my pc 
> to the server fails with the same message in the actlog and with a 
> local message "ANS1592E Failed to initialize SSL protocol". Both my client 
> and my admin use Session Security:
> Transitional.
>
> Thanks for your help in advance!
>
> Kind regards,
> Eric van Loon
> Air France/KLM Storage Engineering
> 
> For information, services and offers, please visit our web site:
> http://www.klm.com. This e-mail and any attachment may contain 
> confidential and privileged material intended for the addressee only.
> If you are not the addressee, you are notified that no part of the 
> e-mail or any attachment may be disclosed, copied or distributed, and 
> that any other action related to this e-mail or attachment is strictly 
> prohibited, and may be unlawful. If you have received this e-mail by 
> error, please notify the sender immediately by return e-mail, and delete this 
> message.
>
> Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or 
> its employees shall not be liable for the incorrect or incomplete 
> transmission of this e-mail or any attachments, nor responsible for any delay 
> in receipt.
> Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal 
> Dutch
> Airlines) is registered in Amstelveen, The Netherlands, with 
> registered number 33014286
> 
>



--
*Zoltan Forray*
Spectrum Protect (p.k.a. TSM) Software & Hardware Administrator Xymon Monitor 
Administrator VMware Administrator Virginia Commonwealth University UCC/Office 
of Technology Services www.ucc.vcu.edu zfor...@vcu.edu - 804-828-4807 Don't be 
a phishing victim - VCU and other reputable organizations will never use email 
to request that you reply with your password, social security number or 
confidential

Re: Influencing order of VM backup.

2018-02-09 Thread Marc Lanteigne

Hi,

You could configure a new DataMover to handle that VM.

In the preview, is the order alphabetical? If so, can you rename the VM?

Marc...

Sent from my iPhone using IBM Verse

On Feb 8, 2018, 11:17:20 PM, steven.har...@btfinancialgroup.com wrote:

From: steven.har...@btfinancialgroup.com
To: ADSM-L@VM.MARIST.EDU
Cc:
Date: Feb 8, 2018, 11:17:20 PM
Subject: [ADSM-L] Influencing order of VM backup.

Hi All
Thanks for the input on my recent query about 7 Year VM backups. I'll let
you know when I decide something.
Moving on..
TSM Server 7.1.1.300 AIX, Datamovers and Storage Agents on Redhat, writing
to Protectier VTL, TSM for VE 7.1.1/2 hybrid.
We can't use the VMware plugin because of separation of duties concerns, so
we edit the DOMAIN.VMFULL lines in the dsm.sys stanzas. VMs have a range of
different sizes that all back up on the same schedule and we'd prefer not to
split this up. The execution order of the VM backups is determined by TSM for
VE, somehow, and can be seen when a backup vm -preview is run.
There are some large VMs that take quite a while to back up, but
unfortunately run late in the execution order, so we overrun our backup window.
Changing the order of the VMs in the DOMAIN.VMFULL statement does not
influence execution order. Is there any way to make the big ones run first?
Thanks
Steve
Steven Harris
TSM Admin/Consultant
Canberra Australia
This message and any attachment is confidential and may be privileged or
otherwise protected from disclosure. You should immediately delete the message
if you are not the intended recipient. If you have received this email by
mistake please delete it from your system; you should not copy the message or
disclose its content to anyone.
This electronic communication may contain general financial product advice
but should not be relied upon or construed as a recommendation of any financial
product. The information has been prepared without taking into account your
objectives, financial situation or needs. You should consider the Product
Disclosure Statement relating to the financial product and consult your
financial adviser before making a decision about whether to acquire, hold or
dispose of a financial product.
For further details on the financial product please go to
https://urldefense.proofpoint.com/v2/url?u=http-3A__www.bt.com.au=DwIFAg=jf_iaSHvJObTbx-siA1ZOg=hMBqtRSV0jXgOdXEmlNk_-O9LHkPCGSh9PJBRSlL8Q4=DP7DwxCOv4YVWwNQ-mQuUUtEM6b1fb2rRkkXefrXlGA=aVJ5Y2IRgiGyROP9MaupUeZM6Y7X6bJW6eHIekbRugI=

Past performance is not a reliable indicator of future performance.

Re: No more client sessions after server upgrade.

2018-02-09 Thread Erwann SIMON

Hi Eric,


The default certificate (indicated by a * on the left) on older version is 
MD5-signed. TLS 1.2 need a SHA-signed certificatee to be the default.
The update/upgrade process should change the default certificate but it seems 
that it does not.

Here are the commands to verify the default certificate and how to change it.

[root@centos7 config]# /usr/local/ibm/gsk8_64/bin/gsk8capicmd_64 -cert -list 
-db cert.kdb -stashed | tail -2
*-  "TSM Server SelfSigned Key"
-   "TSM Server SelfSigned SHA Key"

[root@centos7 config]# /usr/local/ibm/gsk8_64/bin/gsk8capicmd_64 -cert 
-setdefault -db cert.kdb -label "TSM Server SelfSigned SHA Key" -stashed

[root@centos7 config]# /usr/local/ibm/gsk8_64/bin/gsk8capicmd_64 -cert -list 
-db cert.kdb -stashed | tail -2
-   "TSM Server SelfSigned Key"
*-  "TSM Server SelfSigned SHA Key"

After server restart, the "old" MD5-signed certificate labeled "TSM Server 
SelfSigned Key" will be deleted.

PS : On Windows, path of gsk* commands is : C:\Program Files\Common 
Files\Tivoli\TSM\api64\gsk8\bin

I sometimes had to change the PATH : set PATH=C:\Program Files\Common 
Files\Tivoli\TSM\api64\gsk8\lib64:C:\Program Files\Common 
Files\Tivoli\TSM\api64\gsk8\bin:%PATH%

-- 
Best regards / Cordialement / مع تحياتي

Erwann SIMON

- Mail original -
De: "Eric van Loon (ITOPT3) - KLM" 
À: ADSM-L@VM.MARIST.EDU
Envoyé: Vendredi 9 Février 2018 09:39:58
Objet: Re: [ADSM-L] No more client sessions after server upgrade.

Hi guys,
To answer my own question so everybody else will be able to find it though 
ADSM-L. The solution was to generate a new certificate. During server startup I 
noticed the following message:

ANR3336W Default certificate labeled TSM Server SelfSigned Key in key data base 
is down level.

The fix was to stop the server and generate a new one by issuing the following 
command in the instance directory:

gsk8capicmd_64 -cert -setdefault -db cert.kdb -stashed -label "TSM Server 
SelfSigned SHA Key"

Afterwards all clients were working again.
Kind regards,
Eric van Loon
Air France/KLM Storage Engineering


On Mon, Feb 5, 2018 at 10:52 AM, Loon, Eric van (ITOPT3) - KLM < 
eric-van.l...@klm.com> wrote:

> Hi guys!
>
> I just upgraded our engineering server from 7.1.7 to 7.1.8 and clients 
> cannot connect anymore. The only session that is working is the one 
> from the server itself. I opened an admin console through it and when 
> I try to establish and admins session from my pc, it's rejected with 
> the message "ANR8599W The connection with :37404 failed 
> due to an untrusted server certificate. An attempt to reconnect and 
> establish certificate trust might follow." A backup session from my pc 
> to the server fails with the same message in the actlog and with a 
> local message "ANS1592E Failed to initialize SSL protocol". Both my client 
> and my admin use Session Security:
> Transitional.
>
> Thanks for your help in advance!
>
> Kind regards,
> Eric van Loon
> Air France/KLM Storage Engineering
> 
> For information, services and offers, please visit our web site:
> http://www.klm.com. This e-mail and any attachment may contain 
> confidential and privileged material intended for the addressee only.
> If you are not the addressee, you are notified that no part of the 
> e-mail or any attachment may be disclosed, copied or distributed, and 
> that any other action related to this e-mail or attachment is strictly 
> prohibited, and may be unlawful. If you have received this e-mail by 
> error, please notify the sender immediately by return e-mail, and delete this 
> message.
>
> Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or 
> its employees shall not be liable for the incorrect or incomplete 
> transmission of this e-mail or any attachments, nor responsible for any delay 
> in receipt.
> Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal 
> Dutch
> Airlines) is registered in Amstelveen, The Netherlands, with 
> registered number 33014286
> 
>



--
*Zoltan Forray*
Spectrum Protect (p.k.a. TSM) Software & Hardware Administrator Xymon Monitor 
Administrator VMware Administrator Virginia Commonwealth University UCC/Office 
of Technology Services www.ucc.vcu.edu zfor...@vcu.edu - 804-828-4807 Don't be 
a phishing victim - VCU and other reputable organizations will never use email 
to request that you reply with your password, social security number or 
confidential personal information. For more details visit 
http://phishing.vcu.edu/

For information, services and offers, please visit our web site: 
http://www.klm.com. This e-mail and any attachment may contain confidential and 
privileged material intended for the addressee only. If you are not the 
addressee, you are notified that no part of the e-mail or any

Re: Backup db chalenges with 7.1.8

2018-02-09 Thread Loon, Eric van (ITOPT3) - KLM

Hi guys,
For the record: the issue below was caused by a misconfigured API client. On 
one cluster node it was using the hosts IP address as tcpcerveraddress, on the 
other one it used tcpserveraddress localhost. After setting them both to 
localhost the database backup was working again on both nodes.
Kind regards,
Eric van Loon
Air France/KLM Storage Engineering

From: Loon, Eric van (ITOPT3) - KLM
Sent: donderdag 25 januari 2018 13:58
To: ADSM-L 
Subject: Backup db chalenges with 7.1.8

Hi guys,
I'm facing a new challenge because of the security enhancement in 7.1.8. In the 
past I installed 7.1.7 servers on a cluster configuration, which was working 
without any issues. With 7.1.8 TSM starts checking the GUID of the 
$$_TSMDBMGR_$$ node used and this changes as soon as the server switches to the 
other cluster node. This causes the backup to fail:

ANR0406I Session 49 started for node $$_TSMDBMGR_$$ (DB2/Linux) (SSL 
10.70.11.118(58814)).
ANR2987W Session ended because of machine GUID or local host IP address 
mismatch.
ANR3259W Session 49 for node $$_TSMDBMGR_$$ (DB2/Linux) refused - 
$$_TSMDBMGR_$$ node from an untrusted system is not allowed.
ANR0403I Session 49 ended for node $$_TSMDBMGR_$$ (DB2/Linux).

I found the circumvention to specify the parameter DBMTRUSTEDGUIDIGNORE YES in 
the dsmserv.opt, but that looks more like a fix than a solution...
How should one solve this issue properly?
Thanks for any help in advance!
Kind regards,
Eric van Loon
Air France/KLM Storage Engineering


For information, services and offers, please visit our web site: 
http://www.klm.com. This e-mail and any attachment may contain confidential and 
privileged material intended for the addressee only. If you are not the 
addressee, you are notified that no part of the e-mail or any attachment may be 
disclosed, copied or distributed, and that any other action related to this 
e-mail or attachment is strictly prohibited, and may be unlawful. If you have 
received this e-mail by error, please notify the sender immediately by return 
e-mail, and delete this message.

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its 
employees shall not be liable for the incorrect or incomplete transmission of 
this e-mail or any attachments, nor responsible for any delay in receipt.
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch 
Airlines) is registered in Amstelveen, The Netherlands, with registered number 
33014286

Re: No more client sessions after server upgrade.

2018-02-09 Thread Loon, Eric van (ITOPT3) - KLM

Hi guys,
To answer my own question so everybody else will be able to find it though 
ADSM-L. The solution was to generate a new certificate. During server startup I 
noticed the following message:

ANR3336W Default certificate labeled TSM Server SelfSigned Key in key data base 
is down level.

The fix was to stop the server and generate a new one by issuing the following 
command in the instance directory:

gsk8capicmd_64 -cert -setdefault -db cert.kdb -stashed -label "TSM Server 
SelfSigned SHA Key"

Afterwards all clients were working again.
Kind regards,
Eric van Loon
Air France/KLM Storage Engineering

On Mon, Feb 5, 2018 at 10:52 AM, Loon, Eric van (ITOPT3) - KLM < 
eric-van.l...@klm.com> wrote:

> Hi guys!
>
> I just upgraded our engineering server from 7.1.7 to 7.1.8 and clients 
> cannot connect anymore. The only session that is working is the one 
> from the server itself. I opened an admin console through it and when 
> I try to establish and admins session from my pc, it's rejected with 
> the message "ANR8599W The connection with :37404 failed 
> due to an untrusted server certificate. An attempt to reconnect and 
> establish certificate trust might follow." A backup session from my pc 
> to the server fails with the same message in the actlog and with a 
> local message "ANS1592E Failed to initialize SSL protocol". Both my client 
> and my admin use Session Security:
> Transitional.
>
> Thanks for your help in advance!
>
> Kind regards,
> Eric van Loon
> Air France/KLM Storage Engineering
> 
> For information, services and offers, please visit our web site:
> http://www.klm.com. This e-mail and any attachment may contain 
> confidential and privileged material intended for the addressee only.
> If you are not the addressee, you are notified that no part of the 
> e-mail or any attachment may be disclosed, copied or distributed, and 
> that any other action related to this e-mail or attachment is strictly 
> prohibited, and may be unlawful. If you have received this e-mail by 
> error, please notify the sender immediately by return e-mail, and delete this 
> message.
>
> Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or 
> its employees shall not be liable for the incorrect or incomplete 
> transmission of this e-mail or any attachments, nor responsible for any delay 
> in receipt.
> Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal 
> Dutch
> Airlines) is registered in Amstelveen, The Netherlands, with 
> registered number 33014286
> 
>

--
*Zoltan Forray*
Spectrum Protect (p.k.a. TSM) Software & Hardware Administrator Xymon Monitor 
Administrator VMware Administrator Virginia Commonwealth University UCC/Office 
of Technology Services www.ucc.vcu.edu zfor...@vcu.edu - 804-828-4807 Don't be 
a phishing victim - VCU and other reputable organizations will never use email 
to request that you reply with your password, social security number or 
confidential personal information. For more details visit 
http://phishing.vcu.edu/

For information, services and offers, please visit our web site: 
http://www.klm.com. This e-mail and any attachment may contain confidential and 
privileged material intended for the addressee only. If you are not the 
addressee, you are notified that no part of the e-mail or any attachment may be 
disclosed, copied or distributed, and that any other action related to this 
e-mail or attachment is strictly prohibited, and may be unlawful. If you have 
received this e-mail by error, please notify the sender immediately by return 
e-mail, and delete this message. 

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its 
employees shall not be liable for the incorrect or incomplete transmission of 
this e-mail or any attachments, nor responsible for any delay in receipt. 
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch 
Airlines) is registered in Amstelveen, The Netherlands, with registered number 
33014286

SnapDiff threading question

Re: Influencing order of VM backup.

Re: No more client sessions after server upgrade.

Re: Influencing order of VM backup.

Re: No more client sessions after server upgrade.

Re: Backup db chalenges with 7.1.8

Re: No more client sessions after server upgrade.

7 matches

Site Navigation

Mail list logo

Footer information