Re: P7 V7R3 to P9 V7R3 migration recommendations / suggestions

I have a VTL with numerous drives in it. But the same rules apply to
magnetic tape libraries. I did the same thing with tape libraries.

You do not need to move it around at all. No way no how. One card
assigned to VIOS and then virtualized to all lpars works fine. And the
lpars can be doing backups at the same time. You just need to ensure that
the number of drives used by the lpars do not exceed the number of drives
in the library at any one time.


Rob Berendt
--
IBM Certified System Administrator - IBM i 6.1
Group Dekko
Dept 1600
Mail to: 2505 Dekko Drive
Garrett, IN 46738
Ship to: Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com





From: "Evan Harris" <auctionitis@xxxxxxxxx>
To: "Midrange Systems Technical Discussion" <midrange-l@xxxxxxxxxxxx>
Date: 11/01/2018 04:37 PM
Subject: Re: P7 V7R3 to P9 V7R3 migration recommendations /
suggestions
Sent by: "MIDRANGE-L" <midrange-l-bounces@xxxxxxxxxxxx>



This might not be 100% true on a restore for a guest LPAR depending on how
a lot of stuff is configured.
- Is the tape drive configured directly to the guest by moving the card or
is the drive being provided by being virtualised. I am guessing the card
is
being moved in this [particlar case as if there are four drives involved
and it's a library it can't be virtualised for the guest anyway.
- The disk being restored to is a storage space built over physical disk
and made available to the guest via PowerVM so there will be an overhead
for the hosting system serving the disk as well as the logical disk on the
guest. This overhead will be different to just writing to a physical disk
on a system.
- The NWSD might not perform as well as a physical adapter so it might be
worth assigning some memory and configuring a storage pool to help
performance, even if it's only for the restore. This needs to be done up
front as the memory can't be added to the NWSD dynamically. memory added
to
an NWSD kind of acts a little like a dedicated cache as far as I
understand
it.

I probably wouldn't host 3 LPARs in a production LPAR, but I have hosted
DEV LPARs in production systems in the past. if there is just one and it
is
not too busy (i.e. not too much disk IO) then it generally works OK but
the
devs on a really busy system will notice it and the prod users might too,
for instance during restore and things like PTF updates on the guest.

These are just thoughts, the CPU on the newer machines seems to brute
force
a lot of pre-conceived concerns assigned if there is sufficient CPU and
memory.

On Fri, Nov 2, 2018 at 9:25 AM Rob Berendt <rob@xxxxxxxxx> wrote:

Performance has five things involved: disk, memory, processor and tape
and the fifth being the cabling, SAN, I/O port going to the tape. Let's
assume that one saves access paths, it's been changed to the default

many

releases ago.
In a restore the biggest constraint will be tape, then disk. It takes

an

awful lot to stress the connection speed to the tape library. Memory

and

processor concerns follow behind.
We're talking about tape libraries with multiple drives in them. One at

a

time or four at once should not matter to the tape library, since you

have

multiple drives.

The biggest reason for the semi restricted state is that you don't want
users on it trying to do stuff during a full system restore. Not really
to speed up the restore, but it probably helps.


Rob Berendt
--
IBM Certified System Administrator - IBM i 6.1
Group Dekko
Dept 1600
Mail to: 2505 Dekko Drive
Garrett, IN 46738
Ship to: Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com





From: "Musselman, Paul" <pmusselman@xxxxxxxxxxxxxxxx>
To: "Midrange Systems Technical Discussion"

<midrange-l@xxxxxxxxxxxx>

Date: 11/01/2018 04:10 PM
Subject: RE: P7 V7R3 to P9 V7R3 migration recommendations /
suggestions
Sent by: "MIDRANGE-L" <midrange-l-bounces@xxxxxxxxxxxx>



What's the system overhead difference between a single-threaded restore

in

restricted state vs 4-at-a-time in mostly restricted?

I know the system has to read the library header from the tape, then

spend

a lot of time allocating space. In fully-restricted state it doesn't

have

to check for any kind of conflict, and just grabs space then restores
data. In mostly-restricted, you have 4 jobs grabbing for space.

What's the tipping point between the two?

Or has faster system hardware overcome the conflict?

Paul E Musselman
PaulMmn@xxxxxxxxxxxxx


--
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: https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/midrange-l.

Please contact support@xxxxxxxxxxxx for any subscription related
questions.

Help support midrange.com by shopping at amazon.com with our affiliate
link: https://amazon.midrange.com


--
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: https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/midrange-l.

Please contact support@xxxxxxxxxxxx for any subscription related
questions.

Help support midrange.com by shopping at amazon.com with our affiliate
link: https://amazon.midrange.com

--

Regards
Evan Harris
--
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: https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/midrange-l.

Please contact support@xxxxxxxxxxxx for any subscription related
questions.

Help support midrange.com by shopping at amazon.com with our affiliate
link: https://amazon.midrange.com


--
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: https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/midrange-l.

Please contact support@xxxxxxxxxxxx for any subscription related
questions.

Help support midrange.com by shopping at amazon.com with our affiliate
link: https://amazon.midrange.com