5.2 zVM networking

 < Day Day Up > 

5.2 z/VM networking

This section describes the minimum tasks needed to connect your z/VM system to the network. For more details, refer to TCP/IP Planning and Customization, SC24-6019.

There are two z/VM user IDs that provide basic TCP/IP services.


The TCPIP user ID provides the primary TCP/IP service, called the stack. When it is logged on or disconnected, TCP/IP should be running. When it is not logged on, TCP/IP is down.


Owns TCP/IP production resources-the 198, 591, and 592 disks. It is the user ID traditionally used to maintain the TCP/IP environment in z/VM.

At a minimum, the following configuration files must be updated to connect the z/VM TCP/IP to the network:


The TCPIP DATA file defines system parameters used by TCP/IP client applications. It is used to specify configuration information such as the host name of the z/VM host, the user ID of the TCPIP virtual machine, the domain name, and name servers. This information is mostly similar to what you find on Linux in the file /etc/resolv.conf.


The PROFILE TCPIP file contains the information required by

TCP/IP to connect to the network. Minimally, one pair of DEVICE and LINK statements must be defined. The link is assigned a home address. The network routing environment is established with static routes and a default route. Finally, the device has to be started. On a Linux system, this information would be found in several places: /etc/route.conf, /etc/modules.conf, /etc/inetd.conf, or /etc/sysconfig/network/ifcfg-eth0.


The file can be used to separate system programming and network programming responsibilities. The sections that follow do not address the use of this file. Rather, all definitions that can be configured in the file are placed in the USER DIRECT or TCPIP PROFILE files.


It is often helpful to run two TCP/IP stacks on z/VM. It is relatively easy to do with a few changes to configuration files. Then you can continue to run on the system when you take one of the stacks down. If you have more than one TCP/IP stack, it is a good idea to separate production and test systems to simplify dealing with changes in both.

In the following sections, we discuss some basic networking tasks that are commonly done in a z/VM and Linux environment:

  • Give OSA addresses to Linux user IDs

  • Add a guest LAN to the system

  • Add NICs to Linux user IDs

  • Customize TCP/IP

  • Start or stop TCP/IP

  • Dynamically changing TCP/IP

5.2.1 Give OSA addresses to Linux user IDs

In order for z/VM to give OSA addresses to Linux user IDs, it must have OSA addresses defined to it. OSA CHPIDs are defined in the system IOCDS. They can be defined as either shared or reconfigurable. If you want more than one LPAR to be able to use the OSA at the same time, you must define the CHPID as shared. If only a single LPAR needs the OSA, then it is your choice which you use. In the world of OSD CHPIDs, since the definition of IP addresses is no longer "burned into the card" (that is, manually defining and installing the OSA address table (OAT) into the card), sharing a card is greatly simplified.

For example, to define the OSAs for the network connectivity on this project, CHPID 00 is defined as an OSD CHPID in SHR mode. Devices 2C00 through 2C0F are defined (2C00-2C0E are OSA, and 2C0F is OASD). CHPID 03 is defined as an OSD CHPID in SHR mode. Devices 2C60 through 2C6F are defined (2C60-2C6E are OSA, and 2C6F is OASD).

You can query the OSA addresses that are being used with the QUERY OSA command, and the OSA addresses that are available with the QUERY OSA FREE command. For example:

    q osa    OSA  2C00 ATTACHED TO TCPIP    2C00    OSA  2C01 ATTACHED TO TCPIP    2C01    OSA  2C02 ATTACHED TO TCPIP    2C02    OSA  2C04 ATTACHED TO LINUXA   2C04    OSA  2C05 ATTACHED TO LINUXA   2C05    OSA  2C06 ATTACHED TO LINUXA   2C06    OSA  2C08 ATTACHED TO LINUXB   2C08    OSA  2C09 ATTACHED TO LINUXB   2C09    OSA  2C0A ATTACHED TO LINUXB   2C0A    q osa free    OSA  2C03 FREE    , OSA  2C07 FREE    , OSA  2C0B FREE    , OSA  2C0C FREE    OSA  2C0D FREE    , OSA  2C0E FREE    , OSA  2C0F FREE    , OSA  2C20 FREE    OSA  2C21 FREE    , OSA  2C22 FREE    , OSA  2C23 FREE    , OSA  2C24 FREE    OSA  2C25 FREE    , OSA  2C26 FREE    , OSA  2C27 FREE    , OSA  2C28 FREE    ... 


This setup skips one device per OSA triplet (that is, the first triplet is 2C00, 2C01, 2C02, and the second triplet is 2C04, 2C05, 2C06). This model will limit each OSA to 60 TCP/IP stacks (240/4). Some older qeth drivers require the first address to be even. To get to the 80 stacks per OSA, the addresses can be assigned 00, 01, 02 to the first, and 04, 05, 03 to the second, 06, 07, 08 to the 3rd, 0a, 0b, 09 to the fourth, and so on.

Once the z/VM LPAR has OSA addresses, the DEDICATE statement can be used in the user directory entry to "give" the addresses to a Linux user ID. For example, the following statements in the USER DIRECT file under the definition of a user ID will give it two OSA triplets that will support two TCP/IP addresses:

    DEDICATE 2C60 2C60    DEDICATE 2C61 2C61    DEDICATE 2C62 2C62    DEDICATE 2C63 2C63    DEDICATE 2C64 2C64    DEDICATE 2C65 2C65 

If the OSA addresses are given to a Linux user ID in the USER DIRECT file and that user ID is currently logged on, be sure to shut down Linux and log off and back on again, in order to allow the changes to take effect.

If you want to allocate OSA addresses interactively, the ATTACH command can be used to give an OSA triplet (the three ports necessary to support communication) to Linux user IDs that are logged on. For example, to give LINUXB the OSA triplet at address 2C08, 2C09, and 2C0A, the following command can be used:

    att 2c08-2c0a linuxb    2C08-2C0A ATTACHED TO LINUXB 

The channel device layer in Linux allows for this device to be used without shutting down.


All of our examples keep the virtual and real addresses the same. Another method is to give each Linux the OSA devices at the same virtual address, then map them in the directory. This allows you to move things around without impacting the individual Linux guest.

5.2.2 Add a guest LAN to the system

A z/VM Guest LAN provides a method of creating virtual networks. Figure 5-2 on page 75 shows three Linux guests that have both direct OSA connections and z/VM guest LAN connections. Note which aspects of the network are physical and which are virtual.

click to expand
Figure 5-2: Sample Guest LAN configuration

Guest LANs can be one of two types: HiperSockets (the default) or QDIO. A HiperSocket guest LAN is recommended because it might have a slight performance advantage over a QDIO guest LAN, and also because the interface names on Linux will have a prefix of "hsi", which might help distinguish them from physical interfaces (if a QDIO guest LAN is used, both physical ethernet OSAs and virtual guest LAN interfaces will have a prefix of "eth").


Having the same name (for example, eth0) for the network interface, whether you have a shared OSA device or a Guest LAN adapter, could be an advantage because you will not have to change the definitions inside Linux when you move things.

To define a Guest LAN, it is recommended you define the LAN in two ways:

  • Interactively, on the command line, and

  • Permanently, in the SYSTEM CONFIG file

The interactive definition is good for the existing z/VM session, while the definition in the SYSTEM CONFIG file ensures the same LAN will be defined after a re-IPL. In both cases, the syntax is the same. Following is an example of defining a HiperSocket guest LAN named GESTLAN1 via the command line on the MAINT user ID. After the LAN is created, it can be queried with the QUERY LAN command:


The same line should be added to the SYSTEM CONFIG file. To update it, you will probably have to release it as a CP disk using the CPRELEASE command. You can then link to the disk read/write (MR) and access it; for example:

    q cpdisk    Label  Userid    Vdev Mode Stat Vol-ID Rdev Type   StartLoc      EndLoc    MNTCF1 MAINT     0CF1  A   R/O  430RES 0200 CKD         278         306    MNTCF2 MAINT     0CF2  B   R/O  430RES 0200 CKD         307         335    MNTCF3 MAINT     0CF3  C   R/O  430RES 0200 CKD         336         364    cprelease a    CPRELEASE request for disk A scheduled.    HCPZAC6730I CPRELEASE request for disk A completed.    link * cf1 cf1 mr    DASD 0CF1 LINKED R/W; R/O BY     2 USERS    acc cf1 f 

You now have the SYSTEM CONFIG file read/write on your F disk. Back it up and add the DEFINE LAN statement to the end of the file. After modifying the file, it is prudent to check the syntax using the CPSYNTAX command which is on MAINT's 193 disk; for example:

    acc 193 g    cpsyntax system config    CONFIGURATION FILE PROCESSING COMPLETE -- NO ERRORS ENCOUNTERED. 

Then you can bring the MAINT CF1 disk back online via the CPACCESS command:

    rel f    det cf1    DASD 0CF1 DETACHED    cpaccess maint cf1 a    CPACCESS request for mode A scheduled.    HCPZAC6732I CPACCESS request for MAINT's 0CF1 in mode A completed. 

The next time z/VM is IPLed, the guest LAN will be defined from the SYSTEM CONFIG file.

5.2.3 Add network interface cards (NICs) to Linux user IDs

After you have defined the Guest LAN, you need to define virtual network interface cards (NICs) for each Linux image. This can be done interactively using the DEFINE NIC command. However, it is recommended that you define the NIC and couple it automatically by an entry in the USER DIRECT file, or by a directory maintenance product, if you are using one. This is done through the user directory SPECIAL statement.

For example, to define a NIC at addresses 600, 601, and 602 that can connect to the system HiperSocket LAN named GESTLAN1, add the following statement to the USER DIRECT file for each user that will need one. If you are using a PROFILE for Linux user IDs, add the statement to the PROFILE so that the Guest LAN triplet will be defined to all Linux user IDs:


After changing the USER DIRECT, remember to run DIRECTXA to bring your changes online. Also, if any of the Linux user IDs are logged on at the time, be sure each one logs off and back on again so the change can take effect.

If you are using DIRMAINT, the command would be similar. For example, to add a NIC to the user ID LINUXA, the command would be:


5.2.4 Customize TCP/IP

To bring z/VM onto the network, TCP/IP must be customized. This is not complicated, though some network administrators feel the syntax of the configuration files is unusual compared with other systems. The two main configuration files are the TCPIP DATA and the PROFILE TCPIP files. The IFCONFIG command can also be used to configure network interfaces for the z/VM TCP/IP stack, or to display the current configuration. IFCONFIG does not make permanent changes to the network configuration, but it can provide data for this purpose that is compatible with the TCP/IP server configuration file.

Customizing the TCPIP DATA file

Log on to TCPMAINT. The TCPIP DATA file is on the TCPMAINT 198 minidisk, which should be accessed as your D disk. XEDIT the file and make the following changes.

Define the DOMAINORIGIN which is the Domain Name Services (DNS) suffix. For example, our suffix is itso.company.com:

    DOMAINORIGIN itso.company.com 

Define the DNS name server. For example, our server is at IP address


Customizing the PROFILE TCPIP

The PROFILE TCPIP file is also on the TCPMAINT 198 minidisk, which should be accessed as your D disk. The following sections or statements are needed in the PROFILE TCPIP file to put z/VM on the network:

  • A DEVICE and LINK statement

  • A HOME address for the link

  • A GATEWAY and DEFAULTNET statement

  • A START statement

Now we describe the important statements in the file, and give an example of how our TCPIP virtual machine is attached to the network; it uses an OSA express connection.

A DEVICE and a LINK statement

Add two lines to the file and enter the following DEVICE and LINK statements:


This defines the device named OSA2C00D as an OSD. Addresses 2C00, 2C01, and 2C02 are the three addresses of the OSA CHPID that are used. OSA2C00 is the PORTNAME. The LINK statement defines a link named OSA2C00L. The protocol to be used is queued direct I/O (QDIO) protocol over ethernet. This link is associated with the device OSA2C00D. The PRIROUTER parameter specifies that all packets be routed to the VM TCP/IP stack, except those intended for other directly connected stacks. This allows further routing to all hosts on the guest LAN. There can be only one stack on the OSA as primary router.

A HOME address

The HOME statement simply provides a home TCP/IP address for the defined link1:    OSA2C00L 

Just as you associate an IP address with a network device, such as eth0, eth1 in UNIX/Linux, you also use the HOME statement to associate an IP address to LINK name (in this example, OSA2C00L).

GATEWAY statement

Add the following GATEWAY statement to define the 10.28.29 network:

    ; (IP) Network  First        Link      Max. Packet  Subnet      Subnet    ; Address       Hop          Name      Size (MTU)   Mask        Value    ; -----------   ------------ -------   -----------  ----------- --------       9             =            OSA2C00L 1500 

This statement adds a network address of 9, which is accessible through the link named OSA2C00L. The maximum transmission unit (MTU) size is 1500. Defining the subnet mask in this fashion is probably different from what you are used to doing. The subnet mask for this 10 network definition is, and the subnet values are The subnet mask is


A "gotcha" when configuring the TCPIP PROFILE is that the GATEWAY statement must not go past column 72. For historical reasons, columns 73 to 80 cannot be used. This is easy to overlook, as the last set of dashes in the comment end on column 72 and not much space is allotted for that field. If your statement does go past column 72, the error message that results is not especially clear.

DEFAULTNET statement

Next, add the following DEFAULTNET statement:

    DEFAULTNET      OSA2C00L  1492        0 

This defines the default gateway as the host with TCP/IP address

START statement

Finally, add a START statement for the device named OSA2C00D.


This will start the OSA "device".

5.2.5 Start or stop TCPIP

The user ID named TCPIP is called a service machine. It is analogous to a Linux daemon; when a daemon is running, the service is available. When a z/VM service machine is logged on or disconnected, the service is available. Therefore, starting TCP/IP on z/VM is as simple as logging on the user ID TCPIP, and stopping it as simple as logging off.

Starting TCPIP manually

When you are first customizing the TCPIP user ID, it is recommended that you log onto it, press Enter when prompted, and read the messages as the TCP/IP stack begins. After you are sure it will start consistently, you can use the XAUTOLOG command; or better, you can have TCPIP start automatically.

Starting TCPIP automatically

You will probably want TCPIP to start automatically. To do this, log on to the AUTOLOG1 user ID and edit the PROFILE EXEC file. Add the following line:


5.2.6 Dynamically changing TCP/IP

Having to bring TCP/IP up and down may be fine when your system is just being tested. However, when you have a production system, recycling TCP/IP can be a problem.

The OBEYFILE command allows you to make temporary dynamic changes to the system operation and network configuration without stopping and restarting the TCPIP virtual machine. You can maintain different files that contain a subset of the TCP/IP configuration statements and use OBEYFILE to activate them while TCP/IP is running; see "Configuring the TCP/IP Server" in z/VM TCP/IP Planning and Customization, SC24-6019.

 < Day Day Up > 

IBM Lotus Domino 6. 5 for Linux on zSeries Implementation
IBM Lotus Domino 6.5 for Linux on Zseries Implementation
ISBN: 0738491748
EAN: 2147483647
Year: 2003
Pages: 162
Authors: IBM Redbooks

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net