Red Hat Training

26.3. Installation Network Parameters

The following parameters can be used to set up the preliminary network automatically and can be defined in either the parameter file or the CMS configuration file. The parameters in this section are the only parameters that can also be used in a CMS configuration file. All other parameters in other sections must be specified in the parameter file.

NETTYPE="type"

Where type must be one of the following: qeth, lcs, or ctc. The default is qeth.

Choose lcs for:

OSA-2 Ethernet/Token Ring

OSA-Express Fast Ethernet in non-QDIO mode

OSA-Express High Speed Token Ring in non-QDIO mode

Gigabit Ethernet in non-QDIO mode

Choose qeth for:

OSA-Express Fast Ethernet

Gigabit Ethernet (including 1000Base-T)

High Speed Token Ring

HiperSockets

ATM (running Ethernet LAN emulation)

SUBCHANNELS="device_bus_IDs"

Where bus_IDs is a comma-separated list of two or three device bus IDs.

This variable supports OSA devices operating in qdio mode or in non-qdio mode.

When using qdio mode (NETTYPE="qeth"), osa_portname is the portname specified on the OSA device when operating in qeth mode.

When using non-qdio mode (NETTYPE="lcs"), lcs_portnumber is used to pass the relative port number as a decimal integer in the range of 0 through 15.

PORTNO="portnumber"

You can add either PORTNO="0" (to use port 0) or PORTNO="1" (to use port 1 of OSA features with two ports per CHPID) to the CMS configuration file to avoid being prompted for the mode.

LAYER2="value"

Where value can be 0 or 1.

Use LAYER2="0" to operate an OSA or HiperSockets device in layer 3 mode (NETTYPE="qeth"). Use LAYER2="1" for layer 2 mode. For virtual network devices under z/VM this setting must match the definition of the GuestLAN or VSWITCH to which the device is coupled.

To use network services that operate on layer 2 (the Data Link Layer or its MAC sublayer) such as DHCP, layer 2 mode is a good choice.

The qeth device driver default for OSA devices is now layer 2 mode. To continue using the previous default of layer 3 mode, set LAYER2="0" explicitly.

VSWITCH="value"

Where value can be 0 or 1.

Specify VSWITCH="1" when connecting to a z/VM VSWITCH or GuestLAN, or VSWITCH="0" (or nothing at all) when using directly attached real OSA or directly attached real HiperSockets.

MACADDR="MAC_address"

If you specify LAYER2="1" and VSWITCH="0", you can optionally use this parameter to specify a MAC address. Linux requires six colon-separated octets as pairs lower case hex digits - for example, MACADDR=62:a3:18:e7:bc:5f. Note that this is different from the notation used by z/VM.

If you specify LAYER2="1" and VSWITCH="1", you must not specify the MACADDR, because z/VM assigns a unique MAC address to virtual network devices in layer 2 mode.

CTCPROT="value"

Where value can be 0, 1, or 3.

Specifies the CTC protocol for NETTYPE="ctc". The default is 0.

HOSTNAME="string"

Where string is the hostname of the newly-installed Linux instance.

IPADDR="IP"

Where IP is the IP address of the new Linux instance.

NETMASK="netmask"

Where netmask is the netmask.

The netmask supports the syntax of a prefix integer (from 1 to 32) as specified in IPv4 classless interdomain routing (CIDR). For example, you can specify 24 instead of 255.255.255.0, or 20 instead of 255.255.240.0.

GATEWAY="gw"

Where gw is the gateway IP address for this network device.

MTU="mtu"

Where mtu is the Maximum Transmission Unit (MTU) for this network device.

DNS="server1:server2:additional_server_terms:serverN"

Where "server1:server2:additional_server_terms:serverN" is a list of DNS servers, separated by colons. For example:

DNS="10.1.2.3:10.3.2.1"

SEARCHDNS="domain1:domain2:additional_dns_terms:domainN"

Where "domain1:domain2:additional_dns_terms:domainN" is a list of the search domains, separated by colons. For example:

SEARCHDNS="subdomain.domain:domain"

You only need to specify SEARCHDNS= if you specify the DNS= parameter.

DASD=

Defines the DASD or range of DASDs to configure for the installation. For a detailed description of the syntax, refer to the dasd_mod device driver module option described in the chapter on the DASD device driver in Linux on System z Device Drivers, Features, and Commands on Red Hat Enterprise Linux 6.

Linuxrc supports a comma-separated list of device bus IDs or of ranges of device bus IDs with the optional attributes ro, diag, erplog, and failfast. Optionally, you can abbreviate device bus IDs to device numbers with leading zeros stripped. Any optional attributes should be separated by colons and enclosed in parentheses. Optional attributes follow a device bus ID or a range of device bus IDs.

The only supported global option is autodetect. This does not support the specification of non-existent DASDs to reserve kernel device names for later addition of DASDs. Use persistent DASD device names (for example /dev/disk/by-path/...) to enable transparent addition of disks later. Other global options such as probeonly, nopav, or nofcx are not supported by linuxrc.

WWPN is the world wide port name used for routing (often in conjunction with multipathing) and is as a 16-digit hex value (for example 0x50050763050b073d).

FCP_LUN refers to the storage logical unit identifier and is specified as a 16-digit hexadecimal value padded with zeroes to the right (for example 0x4020400100000000).

These variables can be used on systems with FCP devices to activate FCP LUNs such as SCSI disks. Additional FCP LUNs can be activated during the installation interactively or by means of a kickstart file. There is no interactive question for FCP in linuxrc. An example value may look similar to the following:

FCP_1="0.0.fc00 0x50050763050b073d 0x4020400100000000"

Important

Each of the values used in the FCP parameters (for example FCP_1 or FCP_2) are site-specific and are normally supplied by the FCP storage administrator.

The installation program prompts you for any required parameters not specified in the parameter or configuration file except for FCP_n.

Where did the comment section go?

Red Hat's documentation publication system recently went through an upgrade to enable speedier, more mobile-friendly content. We decided to re-evaluate our commenting platform to ensure that it meets your expectations and serves as an optimal feedback mechanism. During this redesign, we invite your input on providing feedback on Red Hat documentation via the discussion platform.