Hide Forgot
1. Who is the customer behind the request? Account: name and acct # Volkswagen AG 7035229 TAM customer: No CSM customer: No Strategic: No 2. What is the nature and description of the request? Add bridge_role in 802-3-ethernet.s390-options using nmcli 3. Why does the customer need this? (List the business requirements here) A use case involving qemu/kvm and openvswitch: The prerequisite is a RHEL running on a LPAR with an OSA adapter. The OSA adapter is connected to a switch with layer2. Configure an openvswitch with the aforementioned adpater as an interface and define that network within libvirt. Every started virtual machine with that network defined can use dedicated IPs which are reachable via that switch connected by the OSA adapter. Works excellent with VLAN(s), too. We use this constellation at the moment for an OpenShift POC. I furthermore use this kind of configuration for any hypervisor vm constellation with a varying amount of OSA adapter and different networks since many years, until now without NetworkManager (most Linux s390x distributions support this via network-scripts, e.g. debian, suse, gentoo, clefos, fedora). 4. How would the customer like to achieve this? (List the functional requirements here) Add bridge_role in 802-3-ethernet.s390-options using nmcli 5. For each functional requirement listed, specify how Red Hat and the customer can test to confirm the requirement is successfully implemented. nmcli con mod encXXX 802-3-ethernet.s390-options bridge_role primary 6. Is there already an existing RFE upstream or in Red Hat Bugzilla? No 7. Does the customer have any specific timeline dependencies and which release would they like to target (i.e. RHEL5, RHEL6)? RHEL 8.4 8. Is the sales team involved in this request and do they have any additional input? No. 9. List any affected packages or components. NetworkManager 10. Would the customer be able to assist in testing this functionality if implemented? Yes FYI:- The options "layer2" and "portno", "bridge_role" is a very important option on s390x OSA adapters, since using openvswitch on them without this option and a dedicated layer2 OSA adapter. Currently available options:- [broadcast_mode, buffer_count, canonical_macaddr, checksumming, ctcprot, fake_broadcast, inter, inter_jumbo, ipato_add4, ipato_add6, ipato_enable, ipato_invert4, ipato_invert6, isolation, lancmd_timeout, large_send, layer2, portname, portno, priority_queueing, protocol, route4, route6, rxip_add4, rxip_add6, sniffer, total, vipa_add4,]
Hi Nimish, Do we have hardware in Red Hat lab allowing developer to code on for this 390-options?
WIP: https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/782
fixed upstream: https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/782 Targeted for rhel-8.5.
Setting FailedQA, since changing 802-3ethernet.s390-options bridge_role=primary via nmcli does nothing. I have tried also other s390-options and none of tried worked. I used plugin=ifcfg-rh (which is default and so it should work).
(In reply to Filip Pokryvka from comment #10) > Setting FailedQA, since changing 802-3ethernet.s390-options > bridge_role=primary via nmcli does nothing. I have tried also other > s390-options and none of tried worked. I used plugin=ifcfg-rh (which is > default and so it should work). fixed by https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/commit/b425793d90a7e02420e7f2b7b6f3c1abd8e393c4 Workarounds: - ensure to also set `ethernet.s390-subchannels` - use keyfile plugin for this profile
Note that NetworkManager itself doesn't actually do anything with these options. All it does, is that you can configure on the connection profile and that they are persisted to disk (either keyfile or ifcfg-rh format). What then happens, s390utils package ships a udev rule and a script ([1]). That script parses ifcfg files, and if it find the OPTIONS= key, then udev writes the sysfs values. [1] http://pkgs.devel.redhat.com/cgit/rpms/s390utils/tree/ccw_init?id=5871612e5a2a6397914e6c5564814dd146da8a62 So this is how it's supposed to work, and thus so far this bug is "fixed". Of course, this doesn't work if the profile is stored in keyfile format. Also, with the deprecation of ifcfg files, s390utils needs to find a different solution (or at least, the solution is only keeping to work, if the user creates ifcfg files also on RHEL9).
(In reply to Thomas Haller from comment #14) > Of course, this doesn't work if the profile is stored in keyfile format. > Also, with the deprecation of ifcfg files, s390utils needs to find a > different solution (or at least, the solution is only keeping to work, if > the user creates ifcfg files also on RHEL9). Please file a bug for support with keyfile format as well.
(In reply to Till Maas from comment #15) > (In reply to Thomas Haller from comment #14) > > > Of course, this doesn't work if the profile is stored in keyfile format. > > Also, with the deprecation of ifcfg files, s390utils needs to find a > > different solution (or at least, the solution is only keeping to work, if > > the user creates ifcfg files also on RHEL9). > > Please file a bug for support with keyfile format as well. bug 1978316
Added tests that NetworkManager stores s390-options. We are not able to test that options are applied, as we do not have capable hardware. Also, it is applied by s390utils, so setting qe_testcoverage+ to NetworkManager part.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory (Moderate: NetworkManager security, bug fix, and enhancement update), and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHSA-2021:4361