Re: Multipathing and booting from SAN LUN
On 7/2/20 5:32 PM, Martha McConaghy wrote: > I've run into something that is a bit beyond my Linux skills at this point. > So, I could use some advice. > > I have several RHEL 7 servers running on z/VM that are booting from SAN LUNs, > not ECKD. That isn't our normal practice, so it is different for me. I use > LOADDEV to define the port and LUN, and dedicate the device addresses to each > server. (All are using NPIV addressing and are zoned to a DS8870 on the > SAN.) Here is what one of the directory entries looks like: > >IPL 2000 >LOADDEV PORT 500507630628D700 >LOADDEV LUN 40004007 >MACHINE ESA 4 >OPTION CHPIDV ONE >DEDICATE 2000 5000 >DEDICATE 3000 6000 > -snip- > I don't know what to do with this situation, though, to get full use of the > 2nd fabric. First there is the IPL issue...how can I have an alternate IPL > address if 2000 doesn't work? Then, there is the issue of Linux once it > boots...not sure how to get multipath drivers introduced after the boot > process is already done. The LUN contains the operating system as well as > data. The IPL issue is the bigger problem. Since IPL is a CP command, if it fails, you're back in CP mode. So, no scripting of multiple attempts. You'll need to issue a different LOADDEV command to specify the other WWID and LUN to try the second path. Perhaps even IPL from the other FCP adapter. I don't believe that can be automated without having something like a SECUSER watching and trying different things if it fails. For the multipathing, you're probably going to need to enable the multipathd service, and them rebuild your initrd so that it gets started there, before your file systems get mounted. Not being familiar with the exact details of Red Hat's setup, all I can say is the commands will be something like: sysctl enable whateverthenameofthemultipathingsservice is, followed by the dracut with whatever parameters normally get used. I don't know that dracut will figure out it should include support for multipathing in the initrd or not. That may be something to run a Google search on. Mark Post -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www2.marist.edu/htbin/wlvindex?LINUX-390
Multipathing and booting from SAN LUN
I've run into something that is a bit beyond my Linux skills at this point. So, I could use some advice. I have several RHEL 7 servers running on z/VM that are booting from SAN LUNs, not ECKD. That isn't our normal practice, so it is different for me. I use LOADDEV to define the port and LUN, and dedicate the device addresses to each server. (All are using NPIV addressing and are zoned to a DS8870 on the SAN.) Here is what one of the directory entries looks like: IPL 2000 LOADDEV PORT 500507630628D700 LOADDEV LUN 40004007 MACHINE ESA 4 OPTION CHPIDV ONE DEDICATE 2000 5000 DEDICATE 3000 6000 This works fine, the servers come up, everything is happy. But, I noticed that only 1 path is used. (We have 2 SAN fabrics for redundancy.) Right now, each server is dependent on path 1 being available in order to boot. Once up, they only use path 1, and would have a problem if that fabric went down. Our usual build for Marist uses ECKD for the operating system, so this isn't an issue. Multipath drivers are used to talk to SAN based LUNs, so we can use both fabrics for redundancy. I don't know what to do with this situation, though, to get full use of the 2nd fabric. First there is the IPL issue...how can I have an alternate IPL address if 2000 doesn't work? Then, there is the issue of Linux once it boots...not sure how to get multipath drivers introduced after the boot process is already done. The LUN contains the operating system as well as data. Any ideas or suggestions? These servers are not "production" yet, but will be eventually. I'd like to be able to get them fixed before that happens. Martha Martha McConaghy Marist: System Architect/Technical Lead SHARE Association: Vice President Marist College IT Poughkeepsie, NY 12601 -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www2.marist.edu/htbin/wlvindex?LINUX-390
Re: KVM question.
Of course z/VM can run any/all IBM Z operating systems, including both z/VSE and Linux. And it can do so within even a single z/VM LPAR. There are some significant resource and operational efficiencies in that sort of configuration. In 2017 IBM announced general availability of sub-capacity licensing for z/VM, so you can now license z/VM one engine at a time. Previously you had to license z/VM for all the IFLs, all the CPs, or both, per machine. Let's suppose for example you have 1 IFL and 3 CPs -- machine capacity model 3907-C03 with 1 IFL as an example. You could configure a z/VM LPAR that spans the IFL and one CP (shared or dedicated), and that would require only 2 engines of z/VM licensing (down from the 4 previously required in this scenario). z/VSE could then run both in its own LPAR(s) and within the z/VM LPAR. Many variations are possible, of course, but that's one sample variation. Either way (or both), I very much like the idea of using a second level hypervisor to run Linux, and to do so right at the beginning. Then you really don't have to give much thought to adding more Linux instances, even if the "new" Linux instances are for release upgrade reasons. It's not hard to do. In fact, in some ways it's easier to start off with a second level hypervisor. - - - - - - - - - - Timothy Sipples I.T. Architect Executive Digital Asset & Other Industry Solutions IBM Z & LinuxONE - - - - - - - - - - E-Mail: sipp...@sg.ibm.com -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www2.marist.edu/htbin/wlvindex?LINUX-390
