|< Day Day Up >|| |
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
Start or stop TCP/IP
Dynamically changing TCP/IP
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.
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.
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:
DEFINE LAN GESTLAN1 MAXCONN 100 OWNERID SYSTEM LAN SYSTEM GESTLAN1 is created q lan LAN SYSTEM GESTLAN1 Type: HIPERS Active: 0 MAXCONN: 100 PERSISTENT UNRESTRICTED MFS: 16384 ACCOUNTING: OFF
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.
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:
SPECIAL 600 HIPER 3 SYSTEM GESTLAN1
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:
DIRM FOR LINUXA SPECIAL 600 QDIO 3 SYSTEM GESTLAN1
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.
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:
Define the DNS name server. For example, our server is at IP address 22.214.171.124:
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.
Add two lines to the file and enter the following DEVICE and LINK statements:
DEVICE OSA2C00D OSD 2C00 PORTNAME OSA2C00 PRIROUTER LINK OSA2C00L QDIOETHERNET OSA2C00D
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.
The HOME statement simply provides a home TCP/IP address for the defined link1:
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).
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 0.255.254.0 0.12.6.0
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 0.255.254.0, and the subnet values are 0.12.6.0. The subnet mask is 255.255.254.0.
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.
Next, add the following DEFAULTNET statement:
DEFAULTNET 126.96.36.199 OSA2C00L 1492 0
This defines the default gateway as the host with TCP/IP address 188.8.131.52.
Finally, add a START statement for the device named OSA2C00D.
This will start the OSA "device".
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.
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.
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:
ADDRESS COMMAND CP XAUTOLOG TCPIP
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 >|| |