A couple weeks ago, in messages with subject "Subchannel not Operational", Joseph Higgins and Jay Brenneman discussed some peculiar behaviour with Linux and multipath I/O. I've got a worse scenario and was hoping it might jog someone's grey matter:
Two VM hosts sharing a couple of DASD strings, and a Linux v-machine defined on both VM hosts (same minidisks), Linux will run on one but will not run on the other. The problem is that Linux can not see some of the minidisks. On the VM host where Linux comes up, the physical volumes have two paths, both operational. On the VM host where it fails, the physical volumes have four paths, only two are operational. (We had a cabling issue; long story; doesn't really matter.) I don't know the I/O subsystem well enough to know if the ORDER of the CHPIDs that VM reports is significant to Linux, but on the host where Linux fails: one is off, one is on, one is off, one is on. So the first and third CHPIDs are off-line. The Linux guest in question lacked too much to come up enough for me to even look at /proc/subchannels. But the kernel messages when it was booting (before root FS was mounted) indicated that it flatly DID NOT SEE the mdisks with the mixed on-line/off-line CHPIDs. (So I doubt /proc/subchannels would have told me anything that I didn't already know.) Anyone got a clue? Want more details? On list / off list? This is not a common scenario, but one that Linux/390 should cope with, since it should philosophically take advantage of this fancy I/O subsystem we've got. Frankly, I don't want *my* customers to lose a Linux volume because the operator had to vary off a couple of paths. Varying off paths is normal stuff in big mainframe shops. -- RMT
