× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



I know, but fortunately I've left vSCSI behind. My last implementations
have been all NPIV, which frees me from that issue. I haven't reached the
128 LUN per vFC limitation yet, and even then we are talking of ASP sizes
above 25 TB.
But yes, once you have all those rules neatly tucked into a cheat sheet,
building systems is a lot easier.
Nowadays I only deal with vSCSI on maintenance customers, and those usually
don't change the config so it's easier.
That is one of the things I love about the redbooks and the Technical
Universities, that you get the distilled know how.


On Mon, Mar 23, 2020 at 4:06 PM Diego E. KESSELMAN <diegokesselman@xxxxxxxxx>
wrote:

Roberto,

remember, you have queue depth limitations (need to calculate between
disks and vSCSI ), disks per vscsi rules and as long as I remember you
can't create as many vSCSI devices for disk as VIOS.

Diego K

El 23/03/20 a las 12:02, Roberto José Etcheverry Romero escribió:
Yes,
That is why the redbooks for IBM i make sure you understand that whatever
size you want to make your LPAR, you have to divide by 200G at the most,
(it actually said LUNs to be between 70 and 200Gb). I don't see the big
issue with having to create those many LUNs, since you can automate LUN
creation and mapping. And even if you do i on i (which I only used on
one
customer to add a Linux LPAR to a small p05 machine) you have to abide by
those rules and you can also automate controller and network storage
creation. It's just scripting...

On Mon, Mar 23, 2020 at 12:01 PM Holger Scherer <hs@xxxxxxx> wrote:

For those who want to verify these important rules:

connect your i to a SAN and give it a single 400GB LUN, then boot LIC,
format disk and install LIC. Monitor SAN usage, you will see about 1/6
up
to 1/8th of the available bandwidth. For example on an 8GBit SAN you
will
see the format goes with about 110-120MB/sec.
Then boot that LIC, create some more LUNs and add them all to the ASP.
You
will see the bandwidth usage go up to a multiple of the 110-120MB/sec
depending on the number of LUNs you're writing to.

Same applies (as Larry wrote) for I/O a single LUN via a single channel
can handle. Even with a big CPU you hardly won't see more than 10k I/O -
but then do this with 40 or 100 LUNs.

I saw this when some business partners went to sell the first SSD or
flash
based IBM DS boxes and created 1TB LUNs for the i...

-h


Am 23.03.2020 um 15:08 schrieb DrFranken <midrange@xxxxxxxxxxxx>:
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list
To post a message email: MIDRANGE-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx
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 thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

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.