Bug 475669 - [LTC 5.4 FEAT] snIPL SCSI LOAD for LPAR [200787]
[LTC 5.4 FEAT] snIPL SCSI LOAD for LPAR [200787]
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: distribution (Show other bugs)
s390x All
high Severity high
: alpha
: 5.4
Assigned To: RHEL Product and Program Management
Release Test Team
: FutureFeature, OtherQA
Depends On:
Blocks: 445204 483784
  Show dependency treegraph
Reported: 2008-12-09 18:30 EST by IBM Bug Proxy
Modified: 2010-03-14 17:28 EDT (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2009-06-05 15:37:24 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

External Trackers
Tracker ID Priority Status Summary Last Updated
IBM Linux Technology Center 50298 None None None Never

  None (edit)
Description IBM Bug Proxy 2008-12-09 18:30:31 EST
=Comment: #0=================================================
Emily J. Ratliff <ratliff@austin.ibm.com> - 
1. Feature Overview:
Feature Id:	[200787]
a. Name of Feature:	snIPL SCSI LOAD for LPAR
b. Feature Description
extend the snIPL tool to allow IPLing (booting) an LPAR from a SCSI/FCP attached disk.

2. Feature Details:
Sponsor:	zSeries

Arch Specificity: Purely Arch Specific Code
Delivery Mechanism: Backport
Category:	zSeries
Request Type:	Package - Feature from IBM
d. Upstream Acceptance:	Accepted
Sponsor Priority	1
f. Severity: High
IBM Confidential:	no
Code Contribution:	IBM code
g. Component Version Target:	snipl

3. Business Case
This feature is required by customers who need to remotely manage (start/stop)
 Linux images in LPARs using SCSI disks.
 In particular this ie required in High Availability setups where automated image starts are needed.

4. Primary contact at Red Hat: 
John Jarvis

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

Technical contact(s):
Reinhard Buendgen, buendgen@de.ibm.com

IBM Manager:
Thomas Schwarz, t.schwarz@de.ibm.com
Comment 1 John Jarvis 2008-12-22 12:33:43 EST
This request is too vague.  What are the precise work items that need to be implemented to satisfy this request?
Comment 2 IBM Bug Proxy 2009-01-09 05:30:37 EST
Hello Red Hat,

this request is about delivering snIPL with RHEL on System z, for which:
+ The latest source code has to be downloaded from DeveloperWorks (new page: http://www.ibm.com/developerworks/linux/linux390/snipl.html )
+ The z/VM HW Interface Library is provided by z/VM and the LPAR HW Interface Library can be downloaded from IBM Resource Link ( http://www.ibm.com/servers/resourcelink/ only accessable to IBM Customers), but we could provide it to you under our NDA.
+ With snIPL source code and the HW Interface Libraries, it should be compiled dynamically and delivered with RHEL (only Binary and snIPL source code, but not the HW Interface Libraries!, since they are not distributable).

snIPL can be used for different management tasks, and within this tasks could be used as fencing mechanism for GFS/2 for RHEL on System z, for which I understood one of the stoppers was not having such a fencing mechanism.

More information can be found under:

Please let us know if you are interested on this feature.

Thank you!
Comment 3 IBM Bug Proxy 2009-01-09 06:11:37 EST
Correction to the last link, the latest version is 2.1.4:
Comment 4 Shawn Wells 2009-01-09 12:44:01 EST
From http://www.ibm.com/developerworks/linux/linux390/snipl.html
snIPL for VM serves as remote control of basic z/VM system management functions. It can be used to reset, activate or deactivate a Linux/VM image for I/O fencing purposes.
This would allow us to start/stop RHEL VMs through Spacewalk/Satellite -- it's something we want.

It looks like we'd need to assign a package manager for this though, as IBM only provides source code (not RPMs).  Is there a process for that?
Comment 6 IBM Bug Proxy 2009-01-23 08:44:15 EST
Source for snipl and library attached before.

(In reply to comment #11)
> Source for snipl and library attached before.

Means  link to source referenced before
Comment 7 John Jarvis 2009-01-28 11:09:30 EST
This would be a new package for RHEL so it would need to go into Fedora first.
Comment 9 Dan Horák 2009-01-29 08:47:42 EST
I took a closer look at this utility and here are my observations:
- cannot live in Fedora, because it is useless without the IBM shipped pieces
- needs IBM bits (noticed in #2) to be fully buildable
- to be installable the IBM bits should be packaged and available in a repository, but some hacks can probably workaround the installability (and repo consistency) issue (ask RH rel-eng?)
- hearbeat is not included in RHEL so the stonith module cannot be built
- shared library called "libconfig.so" for parsing the config file (snipl specific) is installed and such generic name can easily conflict with another library, there already exists a library with same name in Fedora
Comment 10 John Jarvis 2009-01-29 16:09:13 EST
switching component to Distribution since this would be a new package for RHEL.
Comment 11 IBM Bug Proxy 2009-02-18 10:41:03 EST
Update as discussed in the eSDT call:

??? Latest source code has to be downloaded from DeveloperWorks http://www.ibm.com/developerworks/linux/linux390/snipl.html
??? LPAR: Management library ???hwmcaapi??? to be provided by IBM to Red Hat, but without an agreement, not to be delivered by Red Hat to customers; IBM System z customers should download it themselves. If Red Hat would like to provide this library, it could be possible to sign an agreement where IBM allows Red Hat to distribute the library with a separate license to forbid customers to redistribute it.
??? z/VM: ???DMSVSMA.X??? has to be copied from z/VM to the Linux system, but without an agreement, not to be delivered by Red Hat to customers; IBM z/VM customers should copy it themselves. If Red Hat would like to provide this library, it could be possible to sign an agreement where IBM allows Red Hat to distribute the library with a separate license to forbid customers to redistribute it.

Please let us know if you are interested on these feature to work on the agreement between IBM and Red Hat to deliver the IBM licensed libraries to make it easier for the customer and avoid extra downloads.

Thank you!
Comment 12 IBM Bug Proxy 2009-02-25 11:20:29 EST
Hello Red Hat,

There are two options regarding the distribution of snIPL
The IBM preferred option requires a re-distribution agreement between IBM and Red Hat.
Therefore feedback is required on what option Red Hat want to agree
to distribute snIPL

Option A.)
Deliver snIPL rpm binary including two binary libraries (LPAR & zVM
interfaces)  required to work with snIPL.
Possibility to deliver src.rpm including all binary libs for compilation.

Preferred by IBM because its simple for the customer
Need to sign re-distribution agreement of the binary libraries with IBM

Option B.)
Compile snIPL with the libraries IBM provides but to package only the
compiled snIPL binary into the rpm without the needed libraries for snIPL to
work. The customer would have to download the libraries from IBM resource
link (LPAR) and zVM (zVM) to work with snIPL in the desired environment.

Not possible to deliver src.rpm also since libs for compile are not

No need for a re-distribution agreement for the binary libraries
(LPAR & zVM interfaces) with IBM
Comment 13 Bill Nottingham 2009-02-26 11:49:46 EST
RHEL consists of open source code only - we cannot ship closed source code, or
code with library dependnecies on closed-source code, in the base operating
system image.
Comment 14 RHEL Product and Program Management 2009-03-26 13:25:06 EDT
This request was evaluated by Red Hat Product Management for
inclusion, but this component is not scheduled to be updated in
the current Red Hat Enterprise Linux release. If you would like
this request to be reviewed for the next minor release, ask your
support representative to set the next rhel-x.y flag to "?".
Comment 15 IBM Bug Proxy 2009-03-30 06:11:42 EDT
------- Comment From gmuelas@de.ibm.com 2009-03-30 06:01 EDT-------
Hello Red Hat Product Management,
what is the concrete reason to reject this feature for RHEL 5.4?
what would be Red Hat's impact of accepting this feature for RHEL 5.4?

Thank you!
Gonzalo Muelas Serrano.
Comment 16 Bill Nottingham 2009-03-30 16:04:23 EDT
Please read comment #13; this feature is unacceptable by design.
Comment 17 IBM Bug Proxy 2009-03-31 09:20:41 EDT
------- Comment From gmuelas@de.ibm.com 2009-03-31 09:18 EDT-------
Hello Red Hat,

thank you for your concrete answer.
I thought that maybe you would be interested on making an exception to your policy to satisfy customer requests and even attract more new customers needing a fencing mechanism for a cluster file system on RHEL on System z.

If that is not the case, and choose not to make an exception, I guess there is nothing to do with this feature.
Kind Regards,
Gonzalo Muelas Serrano.
Comment 18 IBM Bug Proxy 2009-04-01 04:11:07 EDT
------- Comment From gmuelas@de.ibm.com 2009-04-01 04:04 EDT-------
Hello Red Hat,

I've been thinking about your policy, and if such a policy is only restricted to the base operating system image, IBM would also accept if you could ship it in the Supplementary CD where binary only is shipped.

Summary:  	Red Hat Enterprise Linux Supplementary Software (v. 5 for 64-bit IBM System z Server)
Description: 	Red Hat Enterprise Linux - Server supplementary software with non-standard SLAs and/or licenses (v. 5 for 64-bit IBM System z)

What do you think about this approach?

Thank you!
Gonzalo Muelas Serrano.
Comment 19 John Jarvis 2009-06-05 15:32:57 EDT
Gonzalo, please feel free to request this for the Supplementary CD for RHEL 5.5.  We are out of capacity to do this for 5.4
Comment 20 John Jarvis 2009-06-05 15:37:24 EDT
Since this one is NAK'd for RHEL 5.4 and System z will be pursuing a different approach for 5.5, marking this one CLOSED WONTFIX.
Comment 21 IBM Bug Proxy 2009-07-16 10:50:34 EDT
------- Comment From mgrf@de.ibm.com 2009-07-16 10:42 EDT-------
This feature is rejected by Red Hat for RHEL 5.4.
Closing request "willnotfix" based on the reject.

It is not planned to request the feature again for RHEL 5.5

Note You need to log in before you can comment on or make changes to this bug.