"0xdeadabe" <none@nowhere.net> wrote in message
news:479b5718$0$30705$4c368faf@roadrunner.com...
> 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
>
>
>

Open checkbook! Must be somebody elses checkbook