Red Hat Bugzilla – Bug 463180
[LTC 6.0 FEAT] 201687:Installer - QETH Componentization
Last modified: 2010-10-20 10:18:49 EDT
Emily J. Ratliff <email@example.com> - 2008-09-16 18:21 EDT
1. Feature Overview:
Feature Id: 
a. Name of Feature: Installer - QETH Componentization
b. Feature Description
Together with the QETH Componentization item, there has been a change the way the MAC address is
setup when the OSA interface should work in Layer2 mode:
- In the past, the user needed (mandatory) to give a unique MAC address which should be different
from the default card's MAC address.
- Now (new), the user have the possibility (optional) to give a unique MAC address which should be
different from the default card's MAC address; if the user does not wish to do that, the driver will
generate a MAC address randomly.
That is why the installer should allow this option as something optional and not mandatory like in
Additional Comments: This is the installer part for feature 201066 QETH Componentization
2. Feature Details:
Arch Specificity: Both
Affects Installer: Yes
Delivery Mechanism: Request Red Hat development assistance
Request Type: Installer - Enhancement from Distributor
d. Upstream Acceptance: No Code Required
Sponsor Priority 1
f. Severity: High
IBM Confidential: no
Code Contribution: no
g. Component Version Target: n/a
3. Business Case
These changes will improve the installation experience for customers by making the installation
workflow more usable and efficient, having to introduce/input less values, which will result on an
improvement of the customer satisfaction. But still, if the customer wish to set the MAC address
himself (for example, because of a criteria in his network infrastructure), will have the
possibility, and will be satisfied by the flexibility offered.
4. Primary contact at Red Hat:
5. Primary contacts at Partner:
Project Management Contact:
Hans-Georg Markgraf, firstname.lastname@example.org, Boeblingen 49-7031-16-3978
Gonzalo Muelas Serrano, email@example.com
Thomas Schwarz, firstname.lastname@example.org
How is this different from bug 463177?
Hello Red Hat,
the difference to Bug 463177, is that this (463180 , 463541) is a change in the implementation of the QETH driver and its disciplines (layer2 and layer3) which it is also supported in machines pre-z10, while Bug 463177 is the installer enhancement for the exploitation for HiperSockets Layer2 z10 HW Feature, which is already in RHEL 5.2 (319001).
Wih this feature is also important to know that if no discipline is selected
previous to bring the device online, the QETH network kernel driver per default
will try to bring the device in layer2 discipline (in the past, old driver, was
per default layer3!).
Also, for the layer2 discipline, except for GuestLAN/VSWITCH devices, an
automatically random MAC address will be generated, which can be changed
afterwards manually and which could be different everytime that the device is
Please consider these issues for installation code and documenting this behavior in your Installation Guide.
Gonzalo Muelas Serrano.
I'm not seeing anything here that would make for good documentation, such as:
- why would you choose to configure the interface in such a way?
- what's the advantage of one over the other?
- why would you change the default? Won't that break existing configurations on upgrade?
... and so on.
(In reply to comment #3)
> I'm not seeing anything here that would make for good documentation
Here are links to the pages that I think should be changed (input should be provided by RH Kernel/Network/Documentation Team and IBM will be happy to review the technical content):
Red Hat should document that it support Layer2 and Layer3 and that it should be known if the network device use for the installation support only Layer2, only layer3 or both.
The example redhat.conf should be modified to add also the LAYER2 and PORTNO variables. And explain the values bellow, like done with the others.
Here could be explained what question will be asked, in case of network, things which are not yet in the Installation Guide documeneted like Layer2, MAC Address and PORTNO.
Here it could be mention in reference to DHCP, that DHCP won't work on HiperSockets Layer3 mode.
Here again the variable LAYER2 and PORTNO should be docuemented
Here would be nice to create a new page documenting a usual mistake where a device only support Layer2 or Layer3 is configured in the other mode not supported.
Should be rewritten explaning new upstream implementation and attributes.
Device Drivers, Features, and Commands - SC33-8411-00 (PDF, 7.0MB)
>, such as:
> - why would you choose to configure the interface in such a way?
> - what's the advantage of one over the other?
See table 19 and 20 in pages 101-103 in Device Drivers, Features, and Commands - SC33-8411-00 (mentioned above) showing advantages of Layer2 over Layer3
> - why would you change the default? Won't that break existing configurations
> on upgrade?
We changed because we think it is better to have it as default because of the functionality that it provides. See tables mentioned.
Is upgrade from RHEL 5.x to RHEL 6 going to be supported?
- If yes, then the implementation of this feature should also included to take care of the upgrade, that is, existin Layer3 OSA interfaces, where before in the ifcfg-ethXX in OPTIONS there was no mention of LAYER2 (before Layer3 per default), now the upgrade should add LAYER2=0 to the OPTIONS variable so that the interface still remains in Layer3.
- If no, then the implementation of this feature in the installation and initscripts should only take care of the facts mentioned. Btw, correction to the defaults I mentioned: the default Layer2 only applies for OSA real and virtual, but not for HiperSockets (page 115)
We do not do configuration file munging on upgrades.
Before I ask about what do you understand with "configuration file munging", is upgrade from RHEL 5.x to RHEL 6 going to be supported anyway?
No, we dont plan to support upgrades from RHEL5 to RHEL6
------- Comment From email@example.com 2009-09-14 07:55 EDT-------
ok. I assume the defaults mentioned for QETH with OSA Cards and Hipersockets are clear in the documentation provided:
Device Drivers, Features, and Commands - SC33-8411-02 (PDF, 4.3MB) May 2009
Let me know if you need any other information that the installer should take into consideration.
Thank you for your support,
Approved for making the MAC address field optional instead of mandatory. Anaconda UI impact, kickstart option impact.
To fix this bug in anaconda, we need to do the following:
If qeth is used for a particular device, the prompt for MAC address should be optional rather than mandatory. This possibly affects loader/linuxrc.s390 as well as network.py when writing out config files.
IBM is signed up to test and provide feedback.
I'm hesitant to add a QA ack for this item until we have a testable reference
implementation in fedora first ... can we start to identify, build and test the
(Then when that process is complete we can address the RHEL functionality with
confidence that our specification will match the feature need ...)
------- Comment From firstname.lastname@example.org 2010-01-19 05:27 EDT-------
At this point in time, RHEL 6 on System z is the best "Fedora" on System z we've got.... and RHEL 6 anaconda is being rebased from F13...
Without a working Fedora implementation we are unable to approve this for RHEL 6.0 inclusion. Closing as DEFERRED, resetting flags and moving to the RHEL 6.1 tracker for review for inclusion in that release.
------- Comment From email@example.com 2010-02-11 07:26 EDT-------
This feature is implemented in linuxrc.s390 done by System z.
It has been discussed upstream last year and is upstream with Fedora12.
Feature tests passed on alpha build RHEL6.0-20091130.0
Final feature tests planned on RHEL6 betas
The git commits:
1) take layer mode default from device: http://git.fedorahosted.org/git/anaconda.git?p=anaconda.git;a=commit;h=9249e40f42ffbbdcf42cd1caad72e3d622c7a75b
2) MAC address now optional in general with default taken from device: http://git.fedorahosted.org/git/anaconda.git?p=anaconda.git;a=commit;h=5f0fcf6688d08f83826c2892bb9fc97d6b4d7dd0
Based on comment 18, moving to MODIFIED since this feature has been present
were you able to test this feature with any recent snapshot of RHEL6.0?
I would like to make sure you accept implementation of this feature.
Thank you for your feedback.
Red Hat Enterprise Linux Beta 2 is now available and should resolve
the problem described in this bug report. One or more confirmation reports have already been received confirming this. This report is therefore being closed with a resolution of CURRENTRELEASE. You may reopen this bug report if the solution does not work for you.
------- Comment From firstname.lastname@example.org 2010-09-29 08:54 EDT-------
This feature is verified ok.