s390x z/vm qeth support

[nirik]

Greetings.

We have some s390x z/vm instances running Fedora 35.

They need:

LAYER2=1
SUBCHANNELS=0.0.0900,0.0.0901,0.0.0902
NETTYPE=qeth

In order to see/use their network adapter. If we simply add this to the ifcfg-enc900, things work, but linux-system-roles/network says:

TASK [linux-system-roles.network : Show stderr messages] ********************************************
Monday 04 April 2022  16:42:01 +0000 (0:00:01.048)       0:00:12.286 **********                     
Monday 04 April 2022  16:42:01 +0000 (0:00:01.048)       0:00:12.285 **********                     
ok: [buildvm-s390x-01.s390.fedoraproject.org] => {
    "__network_connections_result.stderr_lines": [
        "[003] <info>  #0, state:up persistent_state:present, 'enc900': update connection enc900, 470
c8f30-235f-4a2d-a9a4-8809b7a2b6a0",
        "[004] <info>  #0, state:up persistent_state:present, 'enc900': up connection enc900, 470c8f3
0-235f-4a2d-a9a4-8809b7a2b6a0 (is-modified)",
        "[005] <info>  #0, state:up persistent_state:present, 'enc900': connection reapply failed: fa
ilure to reapply checkpoint: nm-device-error-quark: Can't reapply changes to '802-3-ethernet.s390-sub
channels' setting (3): {'error': \"nm-device-error-quark: Can't reapply changes to '802-3-ethernet.s3
90-subchannels' setting (3)\", 'success': None}"
    ]

So I guess we need a way to pass this configuration as options?
Happy to provide more info, etc.

[thom311]

the connection reapply failed message is not relevant. It only means the role needs to proceed with a nmcli connection up (after nmcli device reapply failed). That's normal.

what playbook did you use to test this? Since the role does not support s390 options, I don't understand what you tested to get above output.

[nirik]

We installed a z/vm fedora 35 instance. It was configured to have the needed s390x config and worked fine.
We later started setting it's network config via linux-system-roles/network.

We are using rhel-system-roles-1.7.3-2.el8.noarch
We are passing the following connections:

network_connections:
  - autoconnect: yes
    ip:
      address:
        - "{{ enc900_ipv4_ip }}/{{ enc900_ipv4_nm }}"
      dhcp4: no
      dns:
        - "{{ dns1 }}"
        - "{{ dns2 }}"
      dns_search:
        - "{{ dns_search1 }}"
        - "{{ dns_search2 }}"
      gateway4: "{{ enc900_ipv4_gw }}"
    mac: "{{ ansible_default_ipv4.macaddress }}"
    name: enc900
    state: up
    type: ethernet

and the following vars:

dns1: 10.3.163.33
dns2: 10.3.163.34
dns_search1: "iad2.fedoraproject.org"
dns_search2: "fedoraproject.org"
enc900_ipv4_gw: 10.16.0.254
enc900_ipv4_nm: 24
enc900_ipv4_ip: 10.16.0.11

Running that all seemed fine. Then we later rebooted and had no network device. So, the 3 additional lines needed for s390x were gone.

So, I suppose this is just a case of us not knowing that s390x wasn't supported, but perhaps a check could be added if removing those options to warn the user that it may result in problems on s390x if they were set in old confirg but not new?

Are there any plans for s390x support?

[thom311]

when you run the role, it updates the ifcfg file. It does not merge it or try to preserve existing settings (except the route_append_only and rule_append_only flags, which seem ugly because a major point is to fully determine the entire configuration -- with a per-profile granularity).

These s390x parameters are almost not used by NetworkManager itself (except to restrict the profile to a certain device). They are mostly honored by udev rules, which read the ifcfg file (or since recently the keyfile) and apply setting when the device appears. Those udev rules only run when the device appears, so it's expected that you wouldn't notice a change until reboot.

Are there any plans for s390x support?

I think not. Things get done when somebody sends a patch, or when somebody convinces somebody else to write a patch. A bug report or discussion might achieve the latter.

The main problem is just how ugly this scheme is, where udev would read configuration files of NetworkManager and that it can only apply changes once. It would be nicer to have a scheme for configuring udev rules, then at least it's clear who does what.

Printing a warning when the role overwrites s390x parameters seems sensible, in particular, because it possibly means udev will behave differently on next boot.

[sharkcz]

Using the "zdev" (https://github.com/ibm-s390-linux/s390-tools/tree/master/zdev) mechanism it is possible to separate udev and networking configs. It works even now (on any recent Fedora and RHEL >= 8) , but it's still missing support in the installer.

[tyll]

Printing a warning when the role overwrites s390x parameters seems sensible, in particular, because it possibly means udev will behave differently on next boot.

yes, either warning or keeping any settingsproperties that the role does not understand might be a good idea.

What would be needed for s390 support in the role? It needs to expose the three properties s390-subchannels, s390-options and s390-nettype? Another option might be to introduce a network_s390 dictionary that uses the zdev mechanisms.

@nirik would you prefer to have support for this in the network role or use the mechanism that @sharkcz described?

[nirik]

Well, either one would work I guess... having them here would be a tad nicer if the installer doesn't support zdev, since you could then install and run linux-system-roles/networking to configure it.
I do think a warning or error or perhaps a warning with keeping extra config would be good.

Thanks for looking into this!