I spent a lot of time going around with this. The problem seemed to come down to that with the kernel I'm using (2.6.9-42.0.8), the dasd driver doesn't provide vendor and model info in sysfs, so device-mapper-multipath can't match up the devices with a rule set. The newer driver in RHEL5 does provide this, and I was able to get it to work there. If someone else has found a workaround, I'd love to hear it, because we have situations where we'd love to use PAVs, and have been assuming they're not supported till RHEL5.
Incidentally, the "pathvec" message seems to be semi-normal. It also shows up on our multipath FCP devices, but they do work. There's also a syntax issue with the blacklist section of the multipath.conf file, at least on RHEL5. The default blacklist includes dasd*, but there's a "blacklist exceptions" section that's supposed to override this by vendor/model code. That section is invalid unless there's a "blacklist" section, so you can't remove the blacklist entirely. You need to put SOMETHING in the blacklist, even if it's bogus. The "exceptions" bit doesn't appear to work anyway, if "dasd*' is in the blacklist, the devices won't be examined. One more problem was that the mapper uses dasdview to pull the labels from the devices, and uses the labels to match up devices. If you're using minidisks for your non-PAV devices, and you happen to have a duplicate volume label, the mapper creates a multipath group for the pair (in our case, it was / and /var), and they're marked "busy". When the script tries to mount them by base device node, the mounts fail, and the boot process stops. -----Original Message----- From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of Stefan Bader Sent: Friday, June 15, 2007 7:37 AM To: [email protected] Subject: Re: [LINUX-390] PAV and RHEL 4 issue, not found on pathvec Hi Eric, short answer: if "multipath -ll" doesn't show anything, your setup still isn't correct. Now for some more information. Is the output of "multipath -v3" that you sent complete? It sound a bit strange. If DASDs aren't blacklisted there should be some action. The "not found in pathvec" is normal for an inittial run. It just says there hasn't been any information about the paths gathered, yet. You might increase the verbosity level to 6 and send it (proably to me directly, since it gets quite large). So we might see why the multipath volumes aren't created. Mit freundlichem Gruß / Regards, Stefan Bader SW Linux on zSeries Development [EMAIL PROTECTED] IBM Deutschland Entwicklung GmbH Vorsitzender des Aufsichtsrats: Martin Jetter Geschäftsführung: Herbert Kircher Sitz der Gesellschaft: Böblingen Registergericht: Amtsgericht Stuttgart, HRB 243294 ---------------------------------------------------------------------------------- When all other means of communication fail, try words. Linux on 390 Port <[email protected]> wrote on 14.06.2007 17:49:17: > This is not the exact issue I am seeing... > > Here are my results and this is the case before and after the change to > multipath.conf per the bugz workaround. > > # multipath > # > # multipath -v3 > load path identifiers cache > # > # all paths in cache : > # > path dasda not found in pathvec > > ===== path info dasda (mask 0x1f) ===== > path dasdb not found in pathvec > > ===== path info dasdb (mask 0x1f) ===== > path dasdc not found in pathvec > > ===== path info dasdc (mask 0x1f) ===== > path dasdd not found in pathvec > > ===== path info dasdd (mask 0x1f) ===== > md0 blacklisted > ram0 blacklisted > ram10 blacklisted > ram11 blacklisted > ram12 blacklisted > ram13 blacklisted > ram14 blacklisted > ram15 blacklisted > ram1 blacklisted > ram2 blacklisted > ram3 blacklisted > ram4 blacklisted > ram5 blacklisted > ram6 blacklisted > ram7 blacklisted > ram8 blacklisted > ram9 blacklisted > > Interesting enough though iostat has the exact same stats for both > /dev/dasdb and /dev/dasdd and when running pvscan I receive the following: > dasdb 0.00 0.00 0.00 0.00 0.00 0.00 0.00 > 0.00 22.67 0.00 23.33 13.33 0.00 > dasdd 0.00 0.00 0.00 0.00 0.00 0.00 0.00 > 0.00 22.67 0.00 21.67 13.33 0.00 > > pvscan > Found duplicate PV sAHQBBquhyI5mbrj8QdvW3zM4YKXjEod: using /dev/dasdd1 > not /dev/dasdb1 > PV /dev/dasdd1 lvm2 [2.29 GB] > Total: 1 [2.29 GB] / in use: 0 [0 ] / in no VG: 1 [2.29 GB] > > So my question is, is PAV working or not? If it is how can I be certain > it is? multipath -ll returns no data that would lead me to believe > multipathing is working. > > Thoughts / assistance? > > Thanks! > > > Bradford Hinson wrote: > > This looks related to: > > > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=238983 > > > > (see error msg at end of comment 0) > > > > On Thu, 2007-06-14 at 08:56 -0400, Eric Sammons wrote: > > > >> Hi, > >> > >> I am trying to configure PAV on RHEL 4 and am running into a problem. I > >> have been working from the "How to Improve Performance with PAV November > >> 17, 2006" document. > >> > >> So it appears PAV is configured. > >> > >> i.e. > >> > >> DASD 0100 ON DASD 304F R/W 0X0100 SUBCHANNEL = 0000 > >> *DASD 0101 ON DASD 314F R/W 0X0101 SUBCHANNEL = 0001* > >> DASD 0190 3390 520RES R/O 107 CYL ON DASD 300B SUBCHANNEL = 0008 > >> DASD 0191 3390 VM350B R/O 470 CYL ON DASD 350B SUBCHANNEL = 000C > >> DASD 019D 3390 V01W01 R/O 146 CYL ON DASD 330B SUBCHANNEL = 0009 > >> DASD 019E 3390 V01W01 R/O 250 CYL ON DASD 330B SUBCHANNEL = 000A > >> DASD 0200 9336 (VDSK) R/W 524288 BLK ON DASD VDSK SUBCHANNEL = 0016 > >> *DASD 0201 ON DASD 31B0 R/W 0X0101 SUBCHANNEL = 0002* > >> DASD 0592 3390 V01W01 R/O 67 CYL ON DASD 330B SUBCHANNEL = 000B > >> > >> > >> # vmcp q pav 314f > >> Device 314F is a base Parallel Access Volume with the following aliases: > >> 31B0 > >> > >> However, after loading the kernel module: > >> dm_multipath 43792 0 > >> > >> and starting multipathd, oh and modifying the /etc/multipath.conf to > >> comment out the blacklist (and yes I modified the file before starting > >> multipathd) I still get no results when I run mulipath. > >> > >> > >> # multipath > >> # > >> > >> When I run multipath -v3 -d I get the following: > >> > >> load path identifiers cache > >> ux_socket_connect error > >> # > >> # all paths in cache : > >> # > >> path dasda not found in pathvec > >> > >> ===== path info dasda (mask 0x1f) ===== > >> path dasdb not found in pathvec > >> > >> ===== path info dasdb (mask 0x1f) ===== > >> path dasdc not found in pathvec > >> > >> ===== path info dasdc (mask 0x1f) ===== > >> path dasdd not found in pathvec > >> > >> ===== path info dasdd (mask 0x1f) ===== > >> md0 blacklisted > >> ram0 blacklisted > >> ram10 blacklisted > >> ram11 blacklisted > >> ram12 blacklisted > >> ram13 blacklisted > >> ram14 blacklisted > >> ram15 blacklisted > >> ram1 blacklisted > >> ram2 blacklisted > >> ram3 blacklisted > >> ram4 blacklisted > >> ram5 blacklisted > >> ram6 blacklisted > >> ram7 blacklisted > >> ram8 blacklisted > >> ram9 blacklisted > >> > >> > >> I am concerned about the ux_socket_connect error and the not found in > >> pathvec errors. Anyone know what might be going on here? Am I missing > >> something here? > >> > >> thanks! > >> Eric > >> > >> ---------------------------------------------------------------------- > >> For LINUX-390 subscribe / signoff / archive access instructions, > >> send email to [EMAIL PROTECTED] with the message: INFO > LINUX-390 or visit > >> http://www.marist.edu/htbin/wlvindex?LINUX-390 > >> > > -- > > Brad Hinson <[EMAIL PROTECTED]> > > Technical Account Manager > > Red Hat, Inc. > > (888) 733-4281 x44198 > > > > ---------------------------------------------------------------------- > > For LINUX-390 subscribe / signoff / archive access instructions, > > send email to [EMAIL PROTECTED] with the message: INFO > LINUX-390 or visit > > http://www.marist.edu/htbin/wlvindex?LINUX-390 > > > > > > ---------------------------------------------------------------------- > For LINUX-390 subscribe / signoff / archive access instructions, > send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit > http://www.marist.edu/htbin/wlvindex?LINUX-390 ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -------------------------------------------------------- This message w/attachments (message) may be privileged, confidential or proprietary, and if you are not an intended recipient, please notify the sender, do not use or share it and delete it. Unless specifically indicated, this message is not an offer to sell or a solicitation of any investment products or other financial product or service, an official confirmation of any transaction, or an official statement of Merrill Lynch. Subject to applicable law, Merrill Lynch may monitor, review and retain e-communications (EC) traveling through its networks/systems. The laws of the country of each sender/recipient may impact the handling of EC, and EC may be archived, supervised and produced in countries other than the country in which you are located. This message cannot be guaranteed to be secure or error-free. This message is subject to terms available at the following link: http://www.ml.com/e-communications_terms/. By messaging with Merrill Lynch you consent to the foregoing. -------------------------------------------------------- ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
