RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 463180 - [LTC 6.0 FEAT] 201687:Installer - QETH Componentization
Summary: [LTC 6.0 FEAT] 201687:Installer - QETH Componentization
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: anaconda
Version: 6.0
Hardware: s390x
OS: All
high
high
Target Milestone: beta
: 6.0
Assignee: Anaconda Maintenance Team
QA Contact: Release Test Team
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2008-09-22 15:00 UTC by IBM Bug Proxy
Modified: 2010-10-20 14:18 UTC (History)
11 users (show)

Fixed In Version: anaconda-12.38.5-1
Doc Type: Enhancement
Doc Text:
Clone Of:
Environment:
Last Closed: 2010-07-12 12:40:53 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)

Description IBM Bug Proxy 2008-09-22 15:00:48 UTC 
=Comment: #0=================================================
Emily J. Ratliff <emilyr.com> - 2008-09-16 18:21 EDT
1. Feature Overview:
Feature Id:	[201687]
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
the past.

Additional Comments:	This is the installer part for feature 201066 QETH Componentization

2. Feature Details:
Sponsor:	zSeries
Architectures:
s390x

Arch Specificity: Both
Affects Installer: Yes
Delivery Mechanism: Request Red Hat development assistance
Category:	Installation
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: 
John Jarvis
jjarvis

5. Primary contacts at Partner:
Project Management Contact:
Hans-Georg Markgraf, mgrf.com, Boeblingen 49-7031-16-3978

Technical contact(s):
Gonzalo Muelas Serrano, gmuelas.com

IBM Manager:
Thomas Schwarz, t.schwarz.com
Comment 1 Bill Nottingham 2008-10-01 20:37:43 UTC 
How is this different from bug 463177?
Comment 2 Gonzalo Muelas Serrano 2008-10-31 10:52:19 UTC 
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
brought online.

Please consider these issues for installation code and documenting this behavior in your Installation Guide.

Thank you,
Gonzalo Muelas Serrano.
Comment 3 Bill Nottingham 2008-10-31 16:14:14 UTC 
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.
Comment 4 Gonzalo Muelas Serrano 2008-11-03 15:29:51 UTC 
(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):
http://www.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/5.2/html/Installation_Guide/s1-s390-steps-hardware.html
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.

http://www.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/5.2/html/Installation_Guide/s1-s390-steps-vm.html
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.

http://www.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/5.2/html/Installation_Guide/s1-s390-steps-lpar.html
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.

http://www.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/5.2/html/Installation_Guide/s1-netconfig-s390.html
Here it could be mention in reference to DHCP, that DHCP won't work on HiperSockets Layer3 mode.

http://www.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/5.2/html/Installation_Guide/ch-parmfiles.html
Here again the variable LAYER2 and PORTNO should be docuemented

http://www.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/5.2/html/Installation_Guide/s1-trouble-install-s390.html
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.

http://www.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/5.2/html/Installation_Guide/s1-s390info-addnetdevice.html
and http://www.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/5.2/html/Installation_Guide/s3-s390info-qeth.html
Should be rewritten explaning new upstream implementation and attributes.
Please see:
http://www.ibm.com/developerworks/linux/linux390/development_documentation.html
Device Drivers, Features, and Commands - SC33-8411-00 (PDF, 7.0MB)
Chapter 9.

>, 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)
Comment 5 Bill Nottingham 2008-11-03 17:02:51 UTC 
We do not do configuration file munging on upgrades.
Comment 7 Gonzalo Muelas Serrano 2008-11-27 13:59:35 UTC 
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?
Comment 8 Denise Dumas 2009-09-11 20:52:12 UTC 
Hi Gonzalo, 
No, we dont plan to support upgrades from RHEL5 to RHEL6 
Denise
Comment 9 IBM Bug Proxy 2009-09-14 12:01:55 UTC 
------- Comment From gmuelas.com 2009-09-14 07:55 EDT-------
Hello Denise
ok. I assume the defaults mentioned for QETH with OSA Cards and Hipersockets are clear in the documentation provided:
http://www.ibm.com/developerworks/linux/linux390/documentation_dev.html
Device Drivers, Features, and Commands - SC33-8411-02 (PDF, 4.3MB) 	May 2009
Chapter 7.

Let me know if you need any other information that the installer should take into consideration.

Thank you for your support,
Comment 10 Siddharth Nagar 2009-10-20 19:16:46 UTC 
Approved for making the MAC address field optional instead of mandatory. Anaconda UI impact, kickstart option impact.
Comment 11 David Cantrell 2010-01-16 02:32:31 UTC 
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.
Comment 12 John Jarvis 2010-01-18 14:21:04 UTC 
IBM is signed up to test and provide feedback.
Comment 13 Brock Organ 2010-01-18 19:22:40 UTC 
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
changes there? 

(Then when that process is complete we can address the RHEL functionality with
confidence that our specification will match the feature need ...)
Comment 16 IBM Bug Proxy 2010-01-19 10:31:43 UTC 
------- Comment From gmuelas.com 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...
Comment 17 John Jarvis 2010-02-05 16:15:28 UTC 
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 18 IBM Bug Proxy 2010-02-11 12:31:22 UTC 
------- Comment From mgrf.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
Comment 19 David Cantrell 2010-02-11 14:40:23 UTC 
Based on comment 18, moving to MODIFIED since this feature has been present
since anaconda-12.38.5-1.
Comment 25 Jan Stodola 2010-06-21 11:30:28 UTC 
Hello IBM,
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.
Comment 26 Chris Ward 2010-07-12 12:40:53 UTC 
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 27 IBM Bug Proxy 2010-09-29 13:01:53 UTC 
------- Comment From gmuelas.com 2010-09-29 08:54 EDT-------
This feature is verified ok.
Note You need to log in before you can comment on or make changes to this bug.