Re: Who is your go to person for virtual disks?

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