Bug 463180

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
brought online.

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

Thank you,
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):
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)

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?

Hi Gonzalo, 
No, we dont plan to support upgrades from RHEL5 to RHEL6 
Denise

------- 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,

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
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 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...

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 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

Based on comment 18, moving to MODIFIED since this feature has been present
since anaconda-12.38.5-1.

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.

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 gmuelas.com 2010-09-29 08:54 EDT-------
This feature is verified ok.