Destination z article: IBM z/VM's Single System Image feature links systems

[Gabe Goldberg]

Seamless Computing
IBM z/VM's Single System Image feature links systems

If awards were given for vague and over-hyped technology terms, cloud 
computing could be a strong contender. Like the famous fragmented 
elephant description 
, its 
meaning and attributes depend on who's speaking, his or her background 
and experience and (too often) what’s being sold. Cloud computing's 
any/all of scalable technology, shared storage, easily provisioned 
compute images, seamless networking, failover reliability, outage-free 
maintenance and maybe more.


*VM Architectural Enhancement*

For a more down-to-earth implementation that plausibly satisfies those 
reasonable (and not mutually exclusive) requirements, consider z/VM's 
Single System Image (SSI) 
feature.http://www.destinationz.org/Mainframe-Solution/Systems-Administration/Seamless-Computing

http://tinyurl.com/zfz8zdd


--
Gabriel Goldberg, Computers and Publishing, Inc.   g...@gabegold.com
3401 Silver Maple Place, Falls Church, VA 22042   (703) 204-0433
LinkedIn: http://www.linkedin.com/in/gabegoldTwitter: GabeG0


--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/

Re: IBM / SUSE Issues udev name change

[Mark Post]

>>> On 12/30/2016 at 09:42 AM, "Waite, Dick (External)" 
>>> 
wrote: 
> Grand Foggy Day in Darmstadt,
> 
> I wanted to know who's bright idea it was to change between SP-1 and SP-2 

I don't believe this is completely accurate.  See below.

> the format of the udev... This amend and "zypper migration" gives you a good 
> SP-2 but where is the /boot/zipl ? it's got a SP-1 udev interface so can not 
> be found and it's a real PITA to get your system back.
-snip-

> Now I'm all in favour of making better interfaces, but the old interface 
> should still work, at least between

And that is how it should be with SLES12 SP2.

> http://www.ibm.com/support/knowledgecenter/linuxonibm/com.ibm.linux.z.lhdd/l
> hdd_c_scsi_nodes.html
> 
> An IBM paper that says:
> 
> SCSI device names are assigned in the order in which the devices are 
> detected. In a typical SAN environment, this can mean a seemingly arbitrary 
> mapping of names to actual devices that can change between boots. Therefore, 
> using standard device nodes of the form /dev/ where 
>  is 
> the device name that the SCSI stack assigns to a device, can be a challenge.
> 
> SUSE Linux Enterprise Server 12 SP2 provides udev to create device nodes for 
> you. Use the device nodes to identify the corresponding actual device.
> 
> Device nodes that are based on bus IDsEnd of changeStart of changeudev 
> creates device nodes of the form
> 
> /dev/disk/by-path/ccw--fc--lun-
> 
> for whole SCSI device and
> 
> /dev/disk/by-path/ccw--fc--lun--part
> 
> for the th partition, where  is the worldwide port number of the 
> target 
> port and  is the logical unit number that represents the target SCSI 
> device.
> Note: The format of these udev-created device nodes has changed and now 
> matches the common code format. Device nodes of the prior form, 
> ccw--zfcp-: or 
> ccw--zfcp-:-part, 
> are no longer created.

I see those names as _additional_ names, not replacements.  One one of my test 
systems, I booted SP2 and see this:
0:s390vsl133:~ # ll /dev/disk/by-path/
total 0
lrwxrwxrwx 1 root root  9 Jan  3 20:11 
ccw-0.0.fa00-fc-0x500507630500873a-lun-0x40104001 -> ../../sda
lrwxrwxrwx 1 root root 10 Jan  3 20:11 
ccw-0.0.fa00-fc-0x500507630500873a-lun-0x40104001-part1 -> ../../sda1
lrwxrwxrwx 1 root root 10 Jan  3 20:11 
ccw-0.0.fa00-fc-0x500507630500873a-lun-0x40104001-part2 -> ../../sda2
lrwxrwxrwx 1 root root 10 Jan  3 20:11 
ccw-0.0.fa00-fc-0x500507630500873a-lun-0x40104001-part3 -> ../../sda3
lrwxrwxrwx 1 root root  9 Jan  3 20:11 
ccw-0.0.fa00-fc-0x500507630500873a-lun-0x40114011 -> ../../sdb
lrwxrwxrwx 1 root root 10 Jan  3 20:11 
ccw-0.0.fa00-fc-0x500507630500873a-lun-0x40114011-part1 -> ../../sdb1
lrwxrwxrwx 1 root root 10 Jan  3 20:11 
ccw-0.0.fa00-fc-0x500507630500873a-lun-0x40114011-part2 -> ../../sdb2
lrwxrwxrwx 1 root root  9 Jan  3 20:11 
ccw-0.0.fa00-fc-0x500507630510473a-lun-0x40104001 -> ../../sdc
lrwxrwxrwx 1 root root 10 Jan  3 20:11 
ccw-0.0.fa00-fc-0x500507630510473a-lun-0x40104001-part1 -> ../../sdc1
lrwxrwxrwx 1 root root 10 Jan  3 20:11 
ccw-0.0.fa00-fc-0x500507630510473a-lun-0x40104001-part2 -> ../../sdc2
lrwxrwxrwx 1 root root 10 Jan  3 20:11 
ccw-0.0.fa00-fc-0x500507630510473a-lun-0x40104001-part3 -> ../../sdc3
lrwxrwxrwx 1 root root  9 Jan  3 20:11 
ccw-0.0.fa00-fc-0x500507630510473a-lun-0x40114011 -> ../../sdd
lrwxrwxrwx 1 root root 10 Jan  3 20:11 
ccw-0.0.fa00-fc-0x500507630510473a-lun-0x40114011-part1 -> ../../sdd1
lrwxrwxrwx 1 root root 10 Jan  3 20:11 
ccw-0.0.fa00-fc-0x500507630510473a-lun-0x40114011-part2 -> ../../sdd2
lrwxrwxrwx 1 root root  9 Jan  3 20:11 
ccw-0.0.fa00-zfcp-0x500507630500873a:0x40104001 -> ../../sda
lrwxrwxrwx 1 root root 10 Jan  3 20:11 
ccw-0.0.fa00-zfcp-0x500507630500873a:0x40104001-part1 -> ../../sda1
lrwxrwxrwx 1 root root 10 Jan  3 20:11 
ccw-0.0.fa00-zfcp-0x500507630500873a:0x40104001-part2 -> ../../sda2
lrwxrwxrwx 1 root root 10 Jan  3 20:11 
ccw-0.0.fa00-zfcp-0x500507630500873a:0x40104001-part3 -> ../../sda3
lrwxrwxrwx 1 root root  9 Jan  3 20:11 
ccw-0.0.fa00-zfcp-0x500507630500873a:0x40114011 -> ../../sdb
lrwxrwxrwx 1 root root 10 Jan  3 20:11 
ccw-0.0.fa00-zfcp-0x500507630500873a:0x40114011-part1 -> ../../sdb1
lrwxrwxrwx 1 root root 10 Jan  3 20:11 
ccw-0.0.fa00-zfcp-0x500507630500873a:0x40114011-part2 -> ../../sdb2
lrwxrwxrwx 1 root root  9 Jan  3 20:11 
ccw-0.0.fa00-zfcp-0x500507630510473a:0x40104001 -> ../../sdc
lrwxrwxrwx 1 root root 10 Jan  3 20:11 
ccw-0.0.fa00-zfcp-0x500507630510473a:0x40104001-part1 -> ../../sdc1
lrwxrwxrwx 1 root root 10 Jan  3 20:11 
ccw-0.0.fa00-zfcp-0x500507630510473a:0x40104001-part2 -> ../../sdc2
lrwxrwxrwx 1 root root 10 Jan  3 20:11 
ccw-0.0.fa00-zfcp-0x500507630510473a:0x40104001-part3 -> ../../sdc3
lrwxrwxrwx 1 root root  9 Jan  3 20:11 
ccw-0.0.fa00-zfcp-0x50050763051047

Re: Linux on z and OSE

[Peter Webb, Toronto Transit Commission]

Sorry I'm late to the discussion.

Please note that there is a problem with the z13s OSE implementation. When the 
CPC is activated, the OSE configuration is inactivated. The configuration is 
stored correctly and when the OSE OSA is activated through the HMC, it works 
fine. Activating the LPAR does not cause any problems for the OSE.

The problem has been reported by us and I presume a fix is in progress.

Peter 

“It is much easier to be critical than to be correct.” Benjamin Disraeli

-Original Message-
From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of Anderson 
Bassani
Sent: Thursday, December 22, 2016 10:31 AM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: Linux on z and OSE

Some considerations:

I did not found the official answer on the available documents, even the Device 
Drivers for KVM.

Some considerations:
a) it is not possible to include some additional OSA Cards exclusively to test 
KVM for z?
b) I would not recommend run KVM with this OSA type in production for KVM / 
Linux.

Some findings:

1) the KVM 1.1.2 at least have the lcs compiled with it (lan channel station 
device driver)

# cat /etc/os-release
NAME="KVM for IBM z Systems"
VERSION="1.1.2 (Z)"
ID="kvmibm"
ID_LIKE="rhel fedora"
VERSION_ID="1.1.2"
PRETTY_NAME="KVM for IBM z Systems 1.1.2 (Z)"
ANSI_COLOR="0;34"
CPE_NAME="cpe:/o:ibm:kvmibm:1.1.2"
BUILD_ID="20160906"

# modprobe lcs

# lsmod | grep lcs
lcs53853  0
ccwgroup   19383  3 lcs,ctcm,qeth

2) IBM recommends the usage of Open Vswitch for more than 50 Guests
http://www-03.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/PRS5331

So, to use the ovs bridge, you will need to define a primary bridge port, and 
this requires exclusive usage of the OSA port. You will not get that with OSA 
OSE (I believe you are sharing the OSA card with other LPARs).

From KVM System Admin Guide
"Note that only one CCW group device sharing the same OSA adapter port can be 
configured as a primary bridge port"

Command:
echo primary > /sys/class/net/enccw0.0.09a0/device/bridge_role





On Thu, Dec 22, 2016 at 5:07 AM, גדי בן אבי  wrote:

> Hi,
>
> We are about to get a new computer (Z13s) with IFL’s.
>
> Our current OSA card is configured as OSE (non qdio), and there is 
> currently no way to change it.
>
> Does KVM work with OSA cards defined as OSE?
> I know z/VM does.
>
> Once I get the Hypervisor (KVM or z/VM) working, does it matter to the 
> guests how the OSA is defined?
>
> Thanks
>
> Gadi
>
>
>
> לתשומת ליבך, בהתאם לנהלי חברת מלם מערכות בע"מ ו/או כל חברת בת ו/או 
> חברה קשורה שלה (להלן : "החברה") וזכויות החתימה בהן, כל הצעה, התחייבות 
> או מצג מטעם החברה, מחייבים מסמך נפרד וחתום על ידי מורשי החתימה של 
> החברה, הנושא את לוגו החברה או שמה המודפס ובצירוף חותמת החברה. בהעדר 
> מסמך כאמור (לרבות מסמך
> סרוק) המצורף להודעת דואר אלקטרוני זאת, אין לראות באמור בהודעה אלא משום 
> טיוטה לדיון, ואין להסתמך עליה לביצוע פעולה עסקית או משפטית כלשהי. 
> Please note that in accordance with Malam and/or its subsidiaries 
> (hereinafter :
> "Malam") regulations and signatory rights, no offer, agreement, 
> concession or representation is binding on the Malam, unless 
> accompanied by a duly signed separate document (or a scanned version 
> thereof), affixed with the Malam seal.
>
> --
> For LINUX-390 subscribe / signoff / archive access instructions, send 
> email to lists...@vm.marist.edu with the message: INFO LINUX-390 or 
> visit
> http://www.marist.edu/htbin/wlvindex?LINUX-390
> --
> For more information on Linux on System z, visit 
> http://wiki.linuxvm.org/
>


The information transmitted is intended only for the person or entity to which 
it is addressed and may contain confidential and/or privileged material.  Any 
review retransmission dissemination or other use of or taking any action in 
reliance upon this information by persons or entities other than the intended 
recipient or delegate is strictly prohibited.  If you received this in error 
please contact the sender and delete the material from any computer.  The 
integrity and security of this message cannot be guaranteed on the Internet.  
The sender accepts no liability for the content of this e-mail or for the 
consequences of any actions taken on the basis of information provided.  The 
recipient should check this e-mail and any attachments for the presence of 
viruses.  The sender accepts no liability for any damage caused by any virus 
transmitted by this e-mail.  This disclaimer is property of the TTC and must 
not be altered or circumvented in any manner.

Re: systemd Failed unmounting /usr

[Marcy Cortes]

And it did show up in the service stream today.

Marcy

-Original Message-
From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of van 
Sleeuwen, Berry
Sent: Thursday, December 29, 2016 3:59 AM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: [LINUX-390] systemd Failed unmounting /usr

Today I have installed the 1013989 PTF's. After reboot I do not see any "Failed 
unmounting" messages anymore. So it looks like this fix indeed has solved the 
issue.

Thank you for pointing to this fix number.

Regards, Berry.

Met vriendelijke groet/With kind regards/Mit freundlichen Grüßen, Berry van 
Sleeuwen

-Original Message-
From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of Mark Post
Sent: Wednesday, December 21, 2016 1:33 AM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: systemd Failed unmounting /usr

>>> On 12/20/2016 at 03:00 PM, Marcy Cortes  
>>> wrote:

> Do you have a bug number I can reference when I open an SR to get a 
> test fix from SUSE?

1013989


Mark Post

--
For LINUX-390 subscribe / signoff / archive access instructions, send email to 
lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit http://wiki.linuxvm.org/ This 
e-mail and the documents attached are confidential and intended solely for the 
addressee; it may also be privileged. If you receive this e-mail in error, 
please notify the sender immediately and destroy it. As its integrity cannot be 
secured on the Internet, Atos’ liability cannot be triggered for the message 
content. Although the sender endeavours to maintain a computer virus-free 
network, the sender does not warrant that this transmission is virus-free and 
will not be liable for any damages resulting from any virus transmitted. On all 
offers and agreements under which Atos Nederland B.V. supplies goods and/or 
services of whatever nature, the Terms of Delivery from Atos Nederland B.V. 
exclusively apply. The Terms of Delivery shall be promptly submitted to you on 
your request.