Tux on VM

Last updated on:
Sunday, July 06, 2008

Software

Information

Community

News

Fun

Credits




Valid HTML 4.01!
Linux for Big Iron
This information was originally posted to the Linux-390 mailing list on January 23, 2002 by Jim Sibley.

Sharing OSA-E cards is quite simple as the card itself sets up the sharing. No external software, such as OSA/SF is needed. The complications come mostly from OSA2 cards, which require external an external OSA/SF tool to set up the sharing.
  1. Gen the OSA-E card as OSD for QDIO (GBX or FEX) or OSE for LCS (FEX only) (I'm using QDIO with the latest 2.2.16 modules) and indicate that they are SHARED between LPARS.
  2. If you only use one TCP/IP IP address per LPAR, then you can gen for 4 subchannel addresses for QDIO. Each LPAR will see the same 4 addresses (for example: 4D00, 4D01, 4D02, 4D03 each LPAR) and can code the same addresses as a "row" in the OSA card OAT table contain LPAR name, subchannel address, and IP.

    example: this is automatically set up by the OS-E card as the LPAR asks for the device
                 subchannel
       LPAR       address            IP address
       lpar1       4d00              10.32.86.91
                   4d01              10.32.86.91
                   4d02              10.32.86.91
    
       lpar2       4d00              10.32.86.92
                   4d01              10.32.86.92
                   4d02              10.32.86.92
    
  3. The only real problem occurs when you need more than 1 TCP/IP IP address per LPAR because the addresses are assigned at the CHP level so that each LPAR sees the same number of subchannel addresses. The formula for maximum subchannel addresses per LPAR is
    There is a maximum of 240 subchannel addresses on an OS-E
    card with each LPAR seeing the same number of addresses:
    
       # of subchannel addresses/LPAR = (240/number of LPARS)
    
The IOCDS should then reflect the result. For example, 2 LPARS could be genned with 120 subchannels each or 15 LPARS could be genned with 16 subchannel addresses.

Then the number of subchannel addresses needs to be divided up between IP - 2 subchannel addresses for LCS per IP, 3 subchannel addresses for QDIO under VM per IP, and 4 subchannel addresses for QDIO under VM per IP.

Assuming 1 Linux and 1 VM LPAR, the address assignments may be something like:
            subchannel
   LPAR      address    IP address
   lparx       4d00     10.32.86.91
               4d01     10.32.86.91
               4d02     10.32.86.91
                                       vm device
   lparvm      4d00     10.32.86.92     900
               4d01     10.32.86.92     901
               4d02     10.32.86.92     902
               4d03     10.32.86.93     904 <-- Linux must start on 
               4d04     10.32.86.93     905     an even address!
               4d05     10.32.86.93     906
And no, under this scheme, the LPAR that needs the most subchannel/IP addresses cannot use the addresses from the other LPARS, even if they are not used!

As to portname, that is LIC dependent and affects all OS. There is a WCS flash that talks to it. The most often recurring problem seems to be that the CASE has to be the same on all OS and the first OS to IPL sets the portname. So, if VM uses upper case for the portname, Linux must too!
 

Site hosting courtesy of Velocity Software