xCAT/xcat-core
2
0
Fork 0
mirror of https://github.com/xcat2/xcat-core.git synced 2026-09-08 12:40:45 +00:00
Code Issues Releases Wiki Activity

docs(genesis): describe s390x qeth setup

Browse Source
This commit is contained in:
Vinícius Ferrão
2026-09-06 00:26:57 -03:00
parent e1b6797249
commit d62cf52290
2 changed files with 13 additions and 4 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/source/developers/guides/code/genesis_openembedded_plan.rst
+12 -3
View File
@@ -93,9 +93,15 @@ IPv6-only deployment also needs matching support in xCAT server code, DHCP,
boot firmware, and boot configuration. Those changes are outside this layer
and must not be hidden inside the Genesis image.
On ``s390x``, Genesis activates qeth devices before NetworkManager starts. It
accepts the standard ``rd.znet=qeth,read,write,data[,option=value]`` parameter.
Without ``rd.znet``, it activates unconfigured qeth devices in layer 2 mode so
NetworkManager can request DHCP leases. Devices already configured by DPM or
another firmware path are left unchanged.
The ``s390x`` image uses virtio networking under QEMU. QEMU does not emulate
qeth, and Genesis does not yet configure qeth channel groups. Physical LPAR
and z/VM Genesis networking therefore remain unvalidated.
qeth, so the activation service exits without changing the virtio interface.
Physical LPAR and z/VM Genesis networking remain unvalidated.
Genesis does not use the shared CEC serial as an s390x node identifier.
QEMU validation covers network IPL, DHCP option 209, TFTP, and the
network-specific ``pxelinux.cfg``-style configuration written by ``mknb``.
@@ -111,6 +117,7 @@ the xcatd wire protocol.
The boot sequence is split into ordered systemd services:
#. On ``s390x``, Genesis activates qeth channel groups.
#. NetworkManager configures candidate interfaces.
#. The network state service selects a management path.
#. Registration asks xcatd for the node destiny.
@@ -273,7 +280,7 @@ actions.
cannot certify platform firmware, BMC behavior, storage-controller tools,
RDMA firmware operations, GPUs, Secure Boot on vendor firmware, or
board-specific device trees. Physical ``s390x`` support also requires a qeth
activation path and IBM Z LPAR or z/VM validation.
channel test on an IBM Z LPAR or z/VM guest.
References
----------
@@ -286,6 +293,8 @@ References
<https://networkmanager.dev/docs/api/latest/NetworkManager-dispatcher.html>`_
* `QEMU s390x network boot
<https://www.qemu.org/docs/master/system/s390x/bootdevices.html>`_
* `IBM znetconf
<https://www.ibm.com/docs/en/linux-on-systems?topic=linuxonz-znetconf>`_
* `NetworkManager initrd generator
<https://networkmanager.dev/docs/api/latest/nm-initrd-generator.html>`_
* `systemd system extensions
docs/source/guides/admin-guides/references/man8/mknb.8.rst
+1 -1
View File
@@ -48,7 +48,7 @@ Canonical \ ``ppc64``\ images are big-endian. xCAT marks them so \ ``ppc64le``\
riscv64 nodes boot through UEFI firmware and grub2. For riscv64, \ **mknb**\ publishes the Genesis kernel and initramfs and writes one grub2 configuration per network under \ ``/tftpboot/boot/grub2``\ , named \ ``grub.cfg-``\ followed by the network hex prefix, so that \ ``grub2.riscv64``\ loaded by the firmware can start node discovery. The per-node files written by \ **nodeset**\ take priority over these network files. Networks served by a \ ``:noboot``\ interface in \ ``site.dhcpinterfaces``\ get no discovery configuration.
QEMU s390-ccw guests receive a network-specific \ ``pxelinux.cfg``\ -style configuration through DHCP option 209. The firmware resolves this name below \ ``pxelinux.cfg``\ . Leave \ ``noderes.netboot``\ unset while a QEMU s390x node uses Genesis discovery. s390x Genesis does not use the shared IBM Z machine serial as a node identifier. QEMU validation covers network IPL through Genesis startup; the discovery exchange with xcatd remains unvalidated for s390x. Legacy xCAT z/VM operating-system provisioning remains unchanged. Physical LPAR and z/VM Genesis networking remain unvalidated because QEMU does not emulate qeth and Genesis does not yet configure qeth channel groups.
QEMU s390-ccw guests receive a network-specific \ ``pxelinux.cfg``\ -style configuration through DHCP option 209. The firmware resolves this name below \ ``pxelinux.cfg``\ . Leave \ ``noderes.netboot``\ unset while a QEMU s390x node uses Genesis discovery. s390x Genesis does not use the shared IBM Z machine serial as a node identifier. On physical IBM Z systems, Genesis accepts \ ``rd.znet=qeth,read,write,data[,option=value]``\ and activates qeth before NetworkManager starts. Without \ ``rd.znet``\ , it activates unconfigured qeth devices in layer 2 mode. Devices already configured by DPM or firmware are unchanged. QEMU validation covers network IPL through Genesis startup; the discovery exchange with xcatd remains unvalidated for s390x. Legacy xCAT z/VM operating-system provisioning remains unchanged. Physical LPAR and z/VM Genesis networking remain unvalidated because QEMU does not emulate qeth.
Run \ **makedhcp -n**\ after installing the s390x image and before booting s390x nodes. This adds the required DHCP option to existing configurations.