Indeed, the old fashion way could be a solution.
But I recommended to migrate an old p520 to free up 2 slots at the host ports on the DS4800 :-)
A SAN switch would be the best way to solve this but unfortunately the costs are too high...

Thanks for the message!

The LPAR was installed after the MPIO and it was booting with both VIOS connected only through one fibre but i saw the DS4800 flapping on it's controllers not knowing what to do with the LUN.

I tried everything with or without RDAC with or without SDDPCM etc. etc. nothing can work out. The problem that a VIOS can only see one controller can't be solved by a driver.

With SEA this is differen't with dual vios because you have a control channel between the 2 VIOS without a physical link to each other.
With fibre there isn't a control channel from one VIOS to the other so it can't detect that VIOS1 is pulling the LUN away from VIOS2 .
If both VIOS can see both controllers then it does work :-)

Hope i'm being clear at the explanation...

I have never tried to work without a SAN switch so I cannot really comment. I was going to say to read http://www.rootvg.net/content/view/281/89/ but it looks like you followed it, or something like it.

Simple test #1:
turn off one of the VIOS and boot the client. It should come up with one path.
shutdown the vioc lpar.
shutdown the VIOS, boot the other
boot the client lpar again.
Now you can now for sure that both paths are functioning as expected.
Start the second VIOS again, watch for errpt messages and/or if lspath in client shows two paths.

Other question: what the client already installed on the LUN. If so, perhaps the confusion is coming from the sudden switch from single path to MPIO.

If client was already installed - save it as a mksysb to a nim server, and reinstall it. This should force it to use MPIO as the client will be MPIO when the mksysb is restored. Be sure to not discover old devices (you may need to reinstall other network interfaces).

More "advanced" tests.

Since it is a VIOS 2.1, it is also AIX 6.1 which means DAR is not being used by default.

remove the vtd devices you have made.

Switch to root user and...

# manage_disk_drivers
1: DS4100: currently MPIO; supported: RDAC/fcparray, MPIO
2: DS4300: currently MPIO; supported: RDAC/fcparray, MPIO
3: DS4500: currently MPIO; supported: RDAC/fcparray, MPIO
4: DS4700/DS4200: currently MPIO; supported: RDAC/fcparray, MPIO
5: DS4800: currently MPIO; supported: RDAC/fcparray, MPIO

Switch to RDAC using the following command (since you are using DS4800):

# manage_disk_drivers -c 5


Then repeat the steps for dual VIOS. Maybe the MPIO driver does not work (well) with MPIO, but might using RDAC.

Again, I have never worked with dual VIOS with a switch. Maybe it is unsupported.

Keep us posted!

Hello,

I'm trying to configure a DS4800 direct attached to a 9117-MMA (power6) with a Dual VIOS setup.
Every VIOS has only one fibre port attached to the DS4800, and the DS4800 has no more ports available.
I did did a "chdev" on the fcs0 adapter to: dyntrk=no &fc_err_recov=delayed_fail (recommended from IBM if you have no SAN switch) .
I create a LUN on the DS4800 and mapped it to the HBA's from the both VIOS.

"cfgdev" was run from the padmin shell and hdisk2 is created. Chdev was invoked again to put the reserve_policy on no_reserve for hdisk2.
The device was then mapped to a vscsi device with the following command:
mkvdev -vdev hdisk2 -vadapter vhost0 -dev vhdisk2    .

I did the the exact same configuration on VIOS2 but when i try to boot the new LPAR with this hard disk, i get al kinds of error messages including:

IDENTIFIER TIMESTAMP  T C RESOURCE_NAME  DESCRIPTION
DF63A4FE   0624183010 T S vhost0  Virtual SCSI Host Adapter detected an r
00B984B3   0624183010 U H hdisk2  UNDETERMINED ERROR
C48C3EC2   0624183010 I H hdisk2  ARRAY ACTIVE CONTROLLER SWITCH
00B984B3   0624182810 U H hdisk2  UNDETERMINED ERROR
C48C3EC2   0624182810 I H hdisk2  ARRAY ACTIVE CONTROLLER SWITCH
C972F43B   0624182710 T S vhost0  Misbehaved Virtual SCSI Client
C972F43B   0624182010 T S vhost0  Misbehaved Virtual SCSI Client


Any advice would be appriciated