consolidated s390 device configuration - step 2: cleanup #1
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…37046,#1937048) Implements the zfcp part of referenced bugs. This also fixes real customer problems with Live Guest Relocation under z/VM SSI, where the destination has vHBAs with different device bus-IDs. 56-zfcp.rules only triggers on initialization of the zfcp device driver. Even though users had persistently configured vHBAs (with full zfcp paths) in /etc/zfcp.conf, it could not automatically activate the vHBAs on the destination after relocation and thus lost all paths. Zdev persistent config udev rules selectively trigger on hotplug of vHBA devices (and of FC remote ports). The new script zfcpconfmigrate.sh needs to be called at an appropriate time during distribution upgrade. If /etc/zfcp.conf exists, it automatically migrates /etc/zfcp.conf to zdev persistent config and moves the old zfcp.conf to a backup file. To prevent overwriting potentially existing backups of the old persistent configuration, simply use a timestamp so we don't overwrite old migration backups. Signed-off-by: Steffen Maier <[email protected]>
…37046,#1937048)
Implements the dasd part of referenced bugs.
The new script dasdconfmigrate.sh needs to be called at an appropriate time
during distribution upgrade. If /etc/dasd.conf exists, automatically
migrate /etc/dasd.conf to zdev persistent config and move the old dasd.conf
to a backup file. To prevent overwriting potentially existing backups of
the old persistent configuration, simply use a timestamp so we don't
overwrite old migration backups.
Nothing should ever add device bus-IDs to the dasd option for the dasd
kernel module ("dasd.dasd=..." on the kernel command line or corresponding
modprobe.d files with "options dasd dasd=..."). The dasd module option is
supposed to be only used for global settings. Individual DASD devices
should only be configured by means of chzdev.
The only exception is to enable DASDs at boot time for a non-hostonly
initrd such as when booting a distro installer.
Signed-off-by: Steffen Maier <[email protected]>
…37046,#1937048) Implements the s390 channel-attached network device, and thus the last, part of referenced bugs. In contrast to ccw_init, which only seems to configure LAYER2 mode, the new migration script migrates all s390 options from nmconnections and so all options will be effective after migration. The new script znetconfmigrate.sh needs to be called at an appropriate time during distribution upgrade. For any ifcfg or NetworkManager configurations, it automatically migrates the s390-specific part to zdev persistent config, exports a backup file of the old configuration, and removes the s390-specific part from the old configuration. To prevent overwriting potentially existing backups of the old persistent configuration, simply use a timestamp so we don't overwrite old migration backups. Signed-off-by: Steffen Maier <[email protected]>
steffen-maier
force-pushed
the
zdev
branch
2 times, most recently
from
8713b20
to
525044c
Compare
Signed-off-by: Steffen Maier <[email protected]>
Depends on https://github.com/ibm-s390-linux/s390-tools/releases/tag/v2.31.0. Link: rhinstaller/anaconda#5250 (comment) Signed-off-by: Steffen Maier <[email protected]>
…7048)
Do NOT backport this to existing Red Hat Linux distribution major releases.
It would break the still required old persistent device configaration.
Depends on dracut commit ("feat(zfcp): finally remove zfcp handling
consolidated in s390-tools").
Implements the zfcp part of referenced bugs.
Persistent zfcp config is handled by s390-tools zdev dracut module 95zdev
as of
ibm-s390-linux/s390-tools@06a30ae
("zdev/dracut: add rd.zfcp cmdline option handling").
Zdev includes cio_ignore handling. Unfortunately, libblockdev uses
{device,zfcp}_cio_free so we cannot easily remove the latter here.
Signed-off-by: Steffen Maier <[email protected]>
…7048)
Do NOT backport this to existing Red Hat Linux distribution major releases.
It would break the still required old persistent device configaration.
Depends on dracut commits ("feat(dasd): finally remove dasd handling
consolidated in s390-tools") and feat(dasd_mod): finally remove dasd
handling consolidated in s390-tools.
Implements the dasd part of referenced bugs.
Persistent dasd config is handled by s390-tools zdev dracut module 95zdev
as of
ibm-s390-linux/s390-tools@9927023
("zdev/dracut: add rd.dasd cmdline option handling").
Zdev includes cio_ignore handling. Unfortunately, libblockdev uses
{device,dasd}_cio_free so we cannot easily remove the latter here.
Nothing should ever add device bus-IDs to the dasd option for the dasd
kernel module ("dasd.dasd=..." on the kernel command line or corresponding
modprobe.d files with "options dasd dasd=..."). The dasd module option is
supposed to be only used for global settings. Individual DASD devices
should only be configured by means of chzdev.
Note that normalize_dasd_arg is not used here in s390utils but the dracut
modules 80cms and 95dasd have a dependency on it. So strictly speaking it
should live there. But then again 80cms should actually live in anaconda.
So maybe s390utils is the best home for normalize_dasd_arg after all.
Signed-off-by: Steffen Maier <[email protected]>
…7048)
Do NOT backport this to existing Red Hat Linux distribution major releases.
It would break the still required old persistent device configaration.
Implements the s390 channel-attached network, and thus last, part of
referenced bugs.
Persistent s390 channel-attached network config is handled distro agnostic
by dracut as of commit ("feat(znet): use zdev for consolidated device
configuration").
Zdev includes cio_ignore handling.
Signed-off-by: Steffen Maier <[email protected]>
The script is no longer used since dracut commits
("refactor(cms): use consolidated dasd config with zdev from s390-tools")
("feat(dasd): minimize dasd handling consolidated in s390-tools").
which depend on s390-tools commits
ibm-s390-linux/s390-tools@9927023
("zdev/dracut: add rd.dasd cmdline option handling")
making use of
ibm-s390-linux/s390-tools@9b2fb1d
("zdev: add helper to convert from dasd_mod.dasd to zdev config"),
which introduced a simpler and posix compatible shell script.
Signed-off-by: Steffen Maier <[email protected]>
steffen-maier
changed the title
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Consolidate the persistent and dynamic configuration of s390-specific devices in Linux distributions by delegating the configuration to the existing framework
zdevfrom s390-tools.This pull request completes consolidated s390 device configuration in
s390utils.It is step 2, after #2.
Some of the commits [see their descriptions] depend on certain commits from:
This PR include scripts to migrate from the old Red Hat s390 persistent device configuration files to zdev; they can be called by the distro update mechanism (leapp?).
Zdev's job is to perform low-level configuration after which the user gets architecture-independent objects such as block devices, SCSI devices, or network interfaces. Those can and should in turn be configured with existing common code mechanisms. So there's a clear separated layering for configuration duties.
In particular, the s390-specific devices currently are: DASD (traditional disk), ZFCP (scsi), and ZNET representing channel-attached network (QETH incl. OSA and HiperSockets, LCS, CTC). Zdev has a stable command line user interface and abstracts from sysfs and from a persistent configuration representation. Zdev encapsulates configuration details. Systems management code can simply delegate configuration to zdev and thus reduce architecture-specific code.
This improves user experience, serviceability, maintainability, and reduces test effort.
@jstodola @sharkcz this is a pseudo PR not meant to be merged but to provide a review comment opportunity for this patch set