We have migrated a number of guests from ECKD to SAN. The O/S is still on ECKD and will remain there for the foreseeable future.
We've been giving each SAN participant its own pair of FCP adapters. (Two, because our SAN guys have architected for dual path access. But I know of one site which uses four paths instead.) This makes each guest look more like a stand-alone server. To isolate them from each other, we then use N-port ID Virtualization. Thanks to the folks who helped us get all this working! It is quite reliable and performs well. The direct connection presents a whole new administration game, so be prepared! It would be better to give the SAN volumes directly to VM (that is, EDEV) and let VM slice things up into minidisks (or even full-pack or near-full-pack). There was a performance issue with EDEV because it naturally introduces more overhead, so we did not go there at first. IBM has addressed that in DIAG 250. (We have not yet revisitted the Linux driver which would use it. Planning to ... RSN!) Another question about EDEV is whether or not you can share volumes across LPARs. Might require NPIV. With ECKD and traditional IBM I/O fabric sharing works as we all know and love it. I don't know how well a SAN fabric supports that. We would need it. Handing each guest its own HBA (host bus adapter, the open systems term for and FCP adapter) kind of blows one of the reasons to go virtual. By comparison, when VMware plays the SAN game, it does something akin to EDEV and does not (to my knowledge) even offer the ability for a guest to connect directly into SAN space. z/VM can go either way, direct or "pooled". -- R;
