Polani wrote:
> I need one more advice from you , regarding VSCSI . I have just
> implemented a VIOS setup with one VIOS and a large number of client
> Lpars.
>
> I have used same VSCSI 9 (let's say vscsix ) on each client lpar to
> mapp disks for rootvg as well as disks for datavg.
>
> In my environment, rootvg is offcource on a scsi disk , being exported
> from VIOS servers , while datavg are on san disk ( again physically
> attached to FC adapters of VIOS servers).
>
> Question is that , what is best stretegy... Technically possible to
> use same vscsi for rootvg and datavg , but what is best practise ( and
> also from performance point of view)...
>
> I have searched manuals and redbook , nobody says about different
> VSCSI for rootvg and datavg ...
>
> For me , solution works fine and off course more complexity in
> management , if i retain with single vscsi strategy for each client
> lpar....
>
> Any comments or suggestions ...
>

We use SCSI disks exclusively internal to the VIO server, and our SAN
disks get fed to the clients. The way we number our Server/Client
adapters is that we match numbering for both adapters, i.e, server
adapter slot 5 will be slot 5 on the client, and have odds on VIO1 and
evens on VIO2.

We make no distinction between what is rootvg and datavg on the clients,
they all use the same adapters. With the performance of the memory
interconnect, I don't think there is any gain by adding to that
complexity. We dual source our SAN to the VIO servers, so that each
client will have the same LUN provided to it by both VIO servers. We
alternate the primary/secondary flag for the LUNS to the VIO servers. I
can't remember the "chpath" syntax, but basically we make hdisk0 primary
to VIO1, hdisk1 primary to VIO2, and so on.

Now granted, we have an open checkbook on disk resources at this point,
so we can play a little. If you must use SCSI disks to your clients, so
be it, but I would stay away from that. Doing so would either mean no
redundancy, or requiring you to mirror on the client.

I am going to end here, because this was an initial ramble. Pick what
you can from that and we and discuss further.

SG