Kernel SRU request submitted: https://lists.ubuntu.com/archives/kernel-team/2020-May/thread.html#110417 Updating status to 'In Progress'.
** Description changed: + SRU Justification: + ================== + + [Impact] + + * A qeth device on a DPM-managed (HMC) IBM Z machine does not obtain its + MAC address for layer2 OSD interfaces from the OSA Network Adapter, + instead it uses a random MAC address. + + * This can cause connectivity issues in environments where reliable and + pre-determined MAC addresses are required, ie. when doing network + configuration based on DHCP. + + [Fix] + + * Backport 1: https://launchpadlibrarian.net/481647649/0001-s390-qeth- + improve-fallback-to-random-MAC-address.patch + + * Backport 2: https://launchpadlibrarian.net/481647657/0002-s390-qeth- + utilize-virtual-MAC-for-Layer2-OSD-devices.patch + + [Test Case] + + * Bring up a qeth L2 OSD interface in DPM-managed (HMC) LPAR + + * Inspect the interface's MAC address. It should be the same as + displayed in the HMC DPM panels. + + * Due to the fact that a system is needed where the HMC is in DPM moce + (rather than in classic mode) this needs to be tested by IBM. + + [Regression Potential] + + * There is a certain risk for a regression, since OSA devices are the + standard netweork devices on s390x. + + * But static network configurations are still more popular for the + usually long running workload on s390x and not dynamic assignments. + + * On the other hand qeth devices are s390x only, so this will at least + not affect common code or code for other architectures. + + * The modifications are limited to drivers/s390/net/qeth_*. + + * The patches are upstream since quite a while, which speaks for their + stability. + + [Other Info] + + * The upstream patch 21b1702af12e "s390/qeth: improve fallback to random + MAC address" got upstream accepted with 4.18, hence is already in all + Ubuntu release that are newer than bionic + + * And the upstream patch b144b99fff69 "s390/qeth: utilize virtual MAC + for Layer2 OSD devices" got upstream accepted with 5.0, hence is also + already in all Ubuntu release that are newer than bionic. + + __________ + ---Problem Description--- qeth on a DPM-managed IBM Z machine does not obtain its MAC Address for L2 OSD interfaces from the OSA Network Adapter. Instead it uses a random MAC Address. - This causes connectivity issues in setups where a reliable & pre-determined MAC Address is required - ie. when doing network configuration via DHCP. - + This causes connectivity issues in setups where a reliable & pre- + determined MAC Address is required - ie. when doing network + configuration via DHCP. + ---uname output--- Ubuntu 18.04 / vmlinuz-4.15.0-101-generic - - Machine Type = IBM z14 GA2 - + + Machine Type = IBM z14 GA2 + ---Debugger--- A debugger is not configured - + ---Steps to Reproduce--- - - Bring up a qeth L2 OSD interface in DPM-managed LPAR. + - Bring up a qeth L2 OSD interface in DPM-managed LPAR. - Inspect the interface's MAC Address. It should be the same as displayed in the DPM Panels. - + Stack trace output: - no - + no + Oops output: - no - + no + System Dump Info: - The system is not configured to capture a system dump. - + The system is not configured to capture a system dump. + -Attach sysctl -a output output to the bug. - Backport of "s390/qeth: improve fallback to random MAC address" - Backport of "s390/qeth: utilize virtual MAC for Layer2 OSD devices" - This ticket is for 18.04 only. Already available with 20.04 ** Changed in: linux (Ubuntu) Status: Triaged => In Progress ** Changed in: ubuntu-z-systems Status: Triaged => In Progress -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1880834 Title: qeth: utilize virtual MAC for Layer2 OSD devices Status in Ubuntu on IBM z Systems: In Progress Status in linux package in Ubuntu: In Progress Bug description: SRU Justification: ================== [Impact] * A qeth device on a DPM-managed (HMC) IBM Z machine does not obtain its MAC address for layer2 OSD interfaces from the OSA Network Adapter, instead it uses a random MAC address. * This can cause connectivity issues in environments where reliable and pre-determined MAC addresses are required, ie. when doing network configuration based on DHCP. [Fix] * Backport 1: https://launchpadlibrarian.net/481647649/0001-s390-qeth- improve-fallback-to-random-MAC-address.patch * Backport 2: https://launchpadlibrarian.net/481647657/0002-s390-qeth- utilize-virtual-MAC-for-Layer2-OSD-devices.patch [Test Case] * Bring up a qeth L2 OSD interface in DPM-managed (HMC) LPAR * Inspect the interface's MAC address. It should be the same as displayed in the HMC DPM panels. * Due to the fact that a system is needed where the HMC is in DPM moce (rather than in classic mode) this needs to be tested by IBM. [Regression Potential] * There is a certain risk for a regression, since OSA devices are the standard netweork devices on s390x. * But static network configurations are still more popular for the usually long running workload on s390x and not dynamic assignments. * On the other hand qeth devices are s390x only, so this will at least not affect common code or code for other architectures. * The modifications are limited to drivers/s390/net/qeth_*. * The patches are upstream since quite a while, which speaks for their stability. [Other Info] * The upstream patch 21b1702af12e "s390/qeth: improve fallback to random MAC address" got upstream accepted with 4.18, hence is already in all Ubuntu release that are newer than bionic * And the upstream patch b144b99fff69 "s390/qeth: utilize virtual MAC for Layer2 OSD devices" got upstream accepted with 5.0, hence is also already in all Ubuntu release that are newer than bionic. __________ ---Problem Description--- qeth on a DPM-managed IBM Z machine does not obtain its MAC Address for L2 OSD interfaces from the OSA Network Adapter. Instead it uses a random MAC Address. This causes connectivity issues in setups where a reliable & pre- determined MAC Address is required - ie. when doing network configuration via DHCP. ---uname output--- Ubuntu 18.04 / vmlinuz-4.15.0-101-generic Machine Type = IBM z14 GA2 ---Debugger--- A debugger is not configured ---Steps to Reproduce--- - Bring up a qeth L2 OSD interface in DPM-managed LPAR. - Inspect the interface's MAC Address. It should be the same as displayed in the DPM Panels. Stack trace output: no Oops output: no System Dump Info: The system is not configured to capture a system dump. -Attach sysctl -a output output to the bug. Backport of "s390/qeth: improve fallback to random MAC address" Backport of "s390/qeth: utilize virtual MAC for Layer2 OSD devices" This ticket is for 18.04 only. Already available with 20.04 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1880834/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
