|
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 tapemany
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
releases ago.an
In a restore the biggest constraint will be tape, then disk. It takes
awful lot to stress the connection speed to the tape library. Memoryand
processor concerns follow behind.a
We're talking about tape libraries with multiple drives in them. One at
time or four at once should not matter to the tape library, since youhave
multiple drives.<midrange-l@xxxxxxxxxxxx>
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"
Date: 11/01/2018 04:10 PMin
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
restricted state vs 4-at-a-time in mostly restricted?spend
I know the system has to read the library header from the tape, then
a lot of time allocating space. In fully-restricted state it doesn'thave
to check for any kind of conflict, and just grabs space then restoreslist
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
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
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.
midrange.com
