Due to the unfortunate ability of the SATABeast to receive and process requests on all four controllers, failing the NFS array over to the second controller makes no discernible difference to the host: it can still talk to c0, alas.
So the only way we’re going to test this is with some brutal combination of FC zone modification and/or controller shutdown.
This is looking better. Note in the previous post, the scsi_vhci.conf entry conforms to the scsi_inquiry format: that is, eight characters are used for the vendor ID (NEXSAN followed by two spaces), with the product ID appended.
Now the scsi devices appear under /devices/scsi_vhci. However, cfgadm still only shows the first path (ie, the first controller) as configured for each SATABeast; “cfgadm -c configure c4″ still fails.
(more…)
Looks like multipathing via the generic scsi_vhci may be possible. Thus far:
Add this to /kernel/drv/scsi_vhci.conf:
device-type-scsi-options-list = "NEXSAN SATABeast", "symmetric-option";
symmetric-option = 0x1000000;
Currently cfgadm -c configure c4 is failing, complaining about being unable to create device nodes.
Having said that, the single-pathed zpool create Just Works.
Work progresses…