Re: bonding multiple qeth vnics to vswitch?

[Mark Post]

>>> On 1/23/2009 at  1:58 PM, Alan Altmark  wrote: 
-snip-
> A mystery indeed.  As Pieter suggested, seeing the output of QUERY NIC
> DETAILS would be edifying.

s390a13:~ # ifconfig
bond0 Link encap:Ethernet  HWaddr 02:00:00:00:00:06
  inet addr:10.10.220.13  Bcast:10.10.255.255  Mask:255.255.0.0
  inet6 addr: fe80::ff:fe00:6/64 Scope:Link
  UP BROADCAST RUNNING MASTER MULTICAST  MTU:1500  Metric:1
  RX packets:190 errors:0 dropped:0 overruns:0 frame:0
  TX packets:187 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:0
  RX bytes:28619 (27.9 Kb)  TX bytes:18672 (18.2 Kb)

eth1  Link encap:Ethernet  HWaddr 02:00:00:00:00:06
  UP BROADCAST RUNNING SLAVE MULTICAST  MTU:1500  Metric:1
  RX packets:188 errors:0 dropped:0 overruns:0 frame:0
  TX packets:94 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:1000
  RX bytes:28478 (27.8 Kb)  TX bytes:10282 (10.0 Kb)

eth2  Link encap:Ethernet  HWaddr 02:00:00:00:00:06
  UP BROADCAST RUNNING SLAVE MULTICAST  MTU:1500  Metric:1
  RX packets:2 errors:0 dropped:0 overruns:0 frame:0
  TX packets:93 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:1000
  RX bytes:141 (141.0 b)  TX bytes:8390 (8.1 Kb)

loLink encap:Local Loopback
  inet addr:127.0.0.1  Mask:255.0.0.0
  inet6 addr: ::1/128 Scope:Host
  UP LOOPBACK RUNNING  MTU:16436  Metric:1
  RX packets:70 errors:0 dropped:0 overruns:0 frame:0
  TX packets:70 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:0
  RX bytes:5432 (5.3 Kb)  TX bytes:5432 (5.3 Kb)

s390a13:~ # modprobe vmcp
s390a13:~ # vmcp q nic details
Adapter 0800  Type: QDIO  Name: UNASSIGNED  Devices: 3
  Port 0 MAC: 02-00-00-00-00-06  VSWITCH: SYSTEM VSW1
  RX Packets: 20565  Discarded: 281Errors: 0
  TX Packets: 9312   Discarded: 0  Errors: 0
  RX Bytes: 18777364 TX Bytes: 3259316
  Connection Name: HALLOLE   State: Session Established
  Device: 0800  Unit: 000   Role: CTL-READ
  Device: 0801  Unit: 001   Role: CTL-WRITE
  Device: 0802  Unit: 002   Role: DATA
  Options: Ethernet Broadcast
Unicast MAC Addresses:
  02-00-00-00-00-06
Multicast MAC Addresses:
  01-00-5E-00-00-01 IP: 224.0.0.1
  01-00-5E-00-01-16 IP: 224.0.1.22
  01-00-5E-7F-FF-FD IP: 224.127.255.253
  33-33-00-00-00-01 IP: FF02::1
  33-33-FF-00-00-06 IP: FF02::FF00:6
Adapter 0900  Type: QDIO  Name: UNASSIGNED  Devices: 3
  Port 0 MAC: 02-00-00-00-00-0C  VSWITCH: SYSTEM VSW1
  RX Packets: 6  Discarded: 7  Errors: 0
  TX Packets: 246Discarded: 0  Errors: 0
  RX Bytes: 472  TX Bytes: 33372
  Connection Name: HALLOLE   State: Session Established
  Device: 0900  Unit: 000   Role: CTL-READ
  Device: 0901  Unit: 001   Role: CTL-WRITE
  Device: 0902  Unit: 002   Role: DATA
  Options: Ethernet
Unicast MAC Addresses:
  02-00-00-00-00-06 IP: 10.10.220.13
Multicast MAC Addresses:
  01-00-5E-00-00-01 IP: 224.0.0.1
  01-00-5E-00-01-16 IP: 224.0.1.22
  01-00-5E-7F-FF-FD IP: 224.127.255.253
  33-33-00-00-00-01 IP: FF02::1
  33-33-FF-00-00-06 IP: FF02::FF00:6

As you can see the "Port 0 MAC" values are different, but the "Unicast MAC" 
addresses are the same.  But, only the 900 device has an IP address assigned to 
it.  After sending a 14MB file from this guest, the statistics for the two 
interfaces show this:
eth1  Link encap:Ethernet  HWaddr 02:00:00:00:00:06
  UP BROADCAST RUNNING SLAVE MULTICAST  MTU:1500  Metric:1
  RX packets:7543 errors:0 dropped:0 overruns:0 frame:0
  TX packets:6087 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:1000
  RX bytes:648827 (633.6 Kb)  TX bytes:7779899 (7.4 Mb)

eth2  Link encap:Ethernet  HWaddr 02:00:00:00:00:06
  UP BROADCAST RUNNING SLAVE MULTICAST  MTU:1500  Metric:1
  RX packets:17 errors:0 dropped:0 overruns:0 frame:0
  TX packets:6087 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:1000
  RX bytes:2414 (2.3 Kb)  TX bytes:7763120 (7.4 Mb)

As I said, the number of bytes (and in this case packets) are spread pretty 
evenly.  The stats from the VSWITCH perspective are now:
Adapter 0800  Type: QDIO  Name: UNASSIGNED  Devices: 3
  Port 0 MAC: 02-00-00-00-00-06  VSWITCH: SYSTEM VSW1
  RX Packets: 27573  Discarded: 281Errors: 0
  TX Packets: 15178  Discarded: 0  Errors: 0
  RX Bytes: 19403387 TX Bytes: 11014068

Adapter 0900  Type: QDIO  Name: UNASSIGNED  Devices: 3
  Port 0 MAC: 02-00-00-00-00-0C  VSWITCH: SYSTEM VSW1
  RX Packets: 20 D

Re: bonding multiple qeth vnics to vswitch?

[Harder, Pieter]

>A mystery indeed.  As Pieter suggested, seeing the output of QUERY NIC
>DETAILS would be edifying.

Here is the answer on my system:

TSMSERV:~ # vmcp q nic details
Adapter 0C00.P00 Type: QDIO  Name: 0   Devices: 3
  MAC: 02-00-00-02-03-96 VSWITCH: SYSTEM QDIOL
  RX Packets: 92717616   Discarded: 0  Errors: 0
  TX Packets: 44178284   Discarded: 0  Errors: 0
  RX Bytes: 130538115623 TX Bytes: 9051130505
  Connection Name: HALLOLE   State: Session Established
  Device: 0C00  Unit: 000   Role: CTL-READ
  Device: 0C01  Unit: 001   Role: CTL-WRITE
  Device: 0C02  Unit: 002   Role: DATA   vPort: 0079  Index: 0079
  VLAN: 0203
  Options: Ethernet Broadcast
Unicast MAC Addresses:
  02-00-00-02-03-96
Multicast MAC Addresses:
  01-00-5E-00-00-01
  01-00-5E-00-01-16
  01-00-5E-7F-FF-FD
  33-33-00-00-00-01
  33-33-FF-02-03-96
Adapter 1C00.P00 Type: QDIO  Name: 0   Devices: 3
  MAC: 02-00-00-00-00-06 VSWITCH: SYSTEM QDIOL
  RX Packets: 58151  Discarded: 0  Errors: 0
  TX Packets: 13957  Discarded: 0  Errors: 0
  RX Bytes: 2635463  TX Bytes: 21358962
  Connection Name: HALLOLE   State: Session Established
  Device: 1C00  Unit: 000   Role: CTL-READ
  Device: 1C01  Unit: 001   Role: CTL-WRITE
  Device: 1C02  Unit: 002   Role: DATA   vPort: 0080  Index: 0080
  VLAN: 0203
  Options: Ethernet Broadcast
Unicast MAC Addresses:
  02-00-00-02-03-96 IP: 10.2.3.150
Multicast MAC Addresses:
  01-00-5E-00-00-01
  01-00-5E-00-01-16
  01-00-5E-7F-FF-FD
  33-33-00-00-00-01
  33-33-FF-02-03-96


Best regards,
Pieter Harder

pieter.har...@brabantwater.nl
tel  +31-73-6837133 / +31-6-47272537

Brabant Water N.V.
Postbus 1068
5200 BC  's-Hertogenbosch
http://www.brabantwater.nl
Handelsregister: 16005077

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

Re: Z/Linux CKD DASD migration from one DASD Subsystem to another

[Alan Altmark]

On Friday, 01/23/2009 at 03:56 EST, "O'Brien, Dennis L"
 wrote:
> I've seen a number of posts, either here or on IBMVM, that suggest
> changing system ID's for DR.  We don't do that.  We have 18 VM systems.
> They're all somewhat different, or we wouldn't have that many.  There is
> far too much node-dependent code to introduce additional node names for
> DR.  If the code all belonged to the systems area, we might be able to
> manage it, but some of it is application code.

Would something like this work for you?

SYSTEM CONFIG
SYSTEM_IDENTIFIER model1 cpuid1 NODE1
  SYSTEM_IDENTIFIER model2 cpuid2 NODE2
SYSTEM_IDENTIFIER model3 cpuid3 NODE1DR
  SYSTEM_IDENTIFIER model4 cpuid4 NODE2DR
SYSTEM_IDENTIFIER_DEFAULT  DOPESLAP

DEVICES OFFLINE_AT_IPL 0-

NODE1: DEVICES ONLINE_AT_IPL 
NODE2: DEVICES ONLINE_AT_IPL 
NODE1DR: DEVICES ONLINE_AT_IPL 
NODE2DR: DEVICES ONLINE_AT_IPL 
  /* DOPESLAP results in no devices online! */

AUTOLOG1's PROFILE EXEC
VARY ON 0-   /* To bring everything else up. */
 /* Perhaps something less aggressive */

SYSTEM NETID
cpuid1  NODE1  RSCS
cpuid2  NODE2  RSCS
cpuid3  NODE1  RSCS
cpuid4  NODE2  RSCS

Use QUERY USERID when it's important to know WHERE you are and IDENTIFY to
know WHO you are.

Alan Altmark
z/VM Development
IBM Endicott

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

Re: XIP (Execute In Place) for z/Linux running with RedHat 4.6

[Martin, Terry R. (CMS/CTR) (CTR)]

Thanks Shawn

-Original Message-
From: Linux on 390 Port [mailto:linux-...@vm.marist.edu] On Behalf Of
Shawn Wells
Sent: Friday, January 23, 2009 10:25 AM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: XIP (Execute In Place) for z/Linux running with RedHat 4.6

Martin, Terry R. (CMS/CTR) (CTR) wrote:
> Hi
>
>
>
> I am looking into XIP and I am wondering someone can share their
> experiences in terms of setting up XIP and actually running with it.
> Also does RedHat 4.6 support XIP?
>
>
>
> Thanks,
>
>
>
> Terry

Check out "How to use Execute-in-Place Technology with Linux on z/VM,
SC33-8283-00, March 23, 2005" available at
http://awlinux1.alphaworks.ibm.com/developerworks/linux390/docu/l26bhe00
.pdf

Also p166 of the RHEL4 cookbook at
http://linuxvm.org/Present/misc/virt-cookbook-1.pdf, "Creating a
DCSS/XIP2 shared file system"

-Shawn

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

Re: Encryption on a 7060

[Mark Post]

>>> On 1/23/2009 at  4:48 PM, "David L. Craig"  wrote: 
-snip-
> Sigh...  We're running VM/ESA 2.2 which means CP doesn't
> know about the IEEE floating point hardware.  As I see it,
> we can upgrade VM, tell the kernel to use emulation even
> though the hardware is there, or put Debian (and VM) into
> their own LPARs.  Does crypto make heavy use of floating
> point?  Is there a way to virtually network between LPARs?
> Does the kernel parameter support using emulation even
> when the hardware is available?  If you can answer off the
> top of your head, let me know.  Otherwise, I'll figure
> this out next week.

The kernel checks for the hardware.  If it finds it, it uses it.  If not, it 
emulates it.  The version of VM you're running on shouldn't matter in that 
regard.


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

Re: Setting ulimit values

[Mark Post]

>>> On 1/23/2009 at  4:30 PM, "Smith, Ann (ISD, IT)" 
wrote: 
-snip- 
> How should I properly set ulimit values more permanently?
> Do I need to update /etc/security/limits.conf ?

Yes.


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

Re: Z/Linux CKD DASD migration from one DASD Subsystem to another

[Smith, Ann (ISD, IT)]

We currently do not change system id's.
We do however have different IP addresses at DR now - that's fun.
Don't know the network folks's latest plans. Always changing.
They don't consider the impacts to the zVM and zOS support folks who
have to make it work.
  

-Original Message-
From: Linux on 390 Port [mailto:linux-...@vm.marist.edu] On Behalf Of
O'Brien, Dennis L
Sent: Friday, January 23, 2009 3:55 PM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: Z/Linux CKD DASD migration from one DASD Subsystem to
another

Alan Altmark wrote:
>Convenience and Security are rarely bedfellows.  Hopefully you use a 
>different system ID when you're in DR.  Use it to qualify the 
>OFFLINE/ONLINE_AT_IPL so that you get the correct address range
depending
>whether you are at home or abroad.

I've seen a number of posts, either here or on IBMVM, that suggest
changing system ID's for DR.  We don't do that.  We have 18 VM systems.
They're all somewhat different, or we wouldn't have that many.  There is
far too much node-dependent code to introduce additional node names for
DR.  If the code all belonged to the systems area, we might be able to
manage it, but some of it is application code.  E.g.

Select
   When Wordpos(node,'NODE1 NODE2 NODEA NODEC') > 0
  Then Do ...
   When node = 'NODE4'
  Then Do ...
etc

There are valid reasons for this type of code.  Differences in the tape
or DR environments, for example.  These are hardware decisions over
which we have no control.  I can just imagine the havoc changing node
names would have caused when we had OfficeVision.  In the interest of
making the DR environment look as much like production as possible for
our users, we chose to keep the DR node names the same.  That decision
was made many years ago, and processes developed around it.  Changing it
now is off the table.  Even if we just starting to design DR, I don't
know if I'd go for changing node names.

I know this is the Linux list.  In a pure guest environment, this might
be less of an issue.  Some of our nodes have a CMS workload, where the
VM node name definitely matters.

   Dennis O'Brien

39,650

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

This communication, including attachments, is for the exclusive use of 
addressee and may contain proprietary, confidential and/or privileged 
information.  If you are not the intended recipient, any use, copying, 
disclosure, dissemination or distribution is strictly prohibited.  If you are 
not the intended recipient, please notify the sender immediately by return 
e-mail, delete this communication and destroy all copies.


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

Re: Encryption on a 7060

[David L. Craig]

On Tue, Jan 13, 2009 at 12:46:08PM -0600, Adam Thornton wrote:

> On Jan 13, 2009, at 12:16 PM, Mark Post wrote:
>
> On 1/13/2009 at  1:00 PM, "David L. Craig"  wrote:
> >>I curate a museum which includes a uni-CP Multiprise 3000
> >-snip-
> >>Do current distros still support this
> >>platform or will I need something older, and if so, will
> >>current encryption software work on the older distro?
> >
> >SLES10 and RHEL5 are 64-bit only.  Previous versions are 31-bit or
> >64-bit.  The non-commercial distributions, Debian/390, Slack/390,
> >CentOS are mostly 31-bit.  So far as I know, they all include GPG
> >and OpenSSL.
>
> Yeah.  How acceptable this will be depends, really, on the bandwidth
> you need encrypted, because doing crypto on a multiprise is pretty
> slow.  Something that we've had success with (depending on your
> requirements) is to use an outboard x86 box, a private network, and
> some iptables magic to make it transparent to everything else on the
> network but do your crypto where it's cheap.
>
> There are, of course, organizations that will provide support for non-
> major distributions, and at least one that really, really likes
> Debian.  Ask me offline.

Sigh...  We're running VM/ESA 2.2 which means CP doesn't
know about the IEEE floating point hardware.  As I see it,
we can upgrade VM, tell the kernel to use emulation even
though the hardware is there, or put Debian (and VM) into
their own LPARs.  Does crypto make heavy use of floating
point?  Is there a way to virtually network between LPARs?
Does the kernel parameter support using emulation even
when the hardware is available?  If you can answer off the
top of your head, let me know.  Otherwise, I'll figure
this out next week.

--

May the LORD God bless you exceedingly abundantly!

Dave Craig

-  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -
"'So the universe is not quite as you thought it was.
 You'd better rearrange your beliefs, then.
 Because you certainly can't rearrange the universe.'"

--from _Nightfall_  by Asimov/Silverberg

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

Setting ulimit values

[Smith, Ann (ISD, IT)]

I had reset values using ulimit command:
   ulimit -n 4096 
   ulimit  -u 4096
   ulimit - s 10240
Then issued ulimit -a to verify the new values were set
After rebooting the server - whoops the values are gone!

How should I properly set ulimit values more permanently?
Do I need to update /etc/security/limits.conf ?


Ann Smith
Mainframe Systems Support -zVM and zLinux Support
Integrated Technology Delivery
IBM Global Service Integrated Operations At The Hartford 
Work phone: 860-547-6110
Pager: 800-204-6367
Email: mailto:ann.sm...@thehartford.com




This communication, including attachments, is for the exclusive use of 
addressee and may contain proprietary, confidential and/or privileged 
information.  If you are not the intended recipient, any use, copying, 
disclosure, dissemination or distribution is strictly prohibited.  If you are 
not the intended recipient, please notify the sender immediately by return 
e-mail, delete this communication and destroy all copies.


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

Re: Z/Linux CKD DASD migration from one DASD Subsystem to another

[O'Brien, Dennis L]

Alan Altmark wrote:
>Convenience and Security are rarely bedfellows.  Hopefully you use a
>different system ID when you're in DR.  Use it to qualify the
>OFFLINE/ONLINE_AT_IPL so that you get the correct address range
depending
>whether you are at home or abroad.

I've seen a number of posts, either here or on IBMVM, that suggest
changing system ID's for DR.  We don't do that.  We have 18 VM systems.
They're all somewhat different, or we wouldn't have that many.  There is
far too much node-dependent code to introduce additional node names for
DR.  If the code all belonged to the systems area, we might be able to
manage it, but some of it is application code.  E.g.

Select
   When Wordpos(node,'NODE1 NODE2 NODEA NODEC') > 0
  Then Do ...
   When node = 'NODE4'
  Then Do ...
etc

There are valid reasons for this type of code.  Differences in the tape
or DR environments, for example.  These are hardware decisions over
which we have no control.  I can just imagine the havoc changing node
names would have caused when we had OfficeVision.  In the interest of
making the DR environment look as much like production as possible for
our users, we chose to keep the DR node names the same.  That decision
was made many years ago, and processes developed around it.  Changing it
now is off the table.  Even if we just starting to design DR, I don't
know if I'd go for changing node names.

I know this is the Linux list.  In a pure guest environment, this might
be less of an issue.  Some of our nodes have a CMS workload, where the
VM node name definitely matters.

   Dennis O'Brien

39,650

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

Re: Z/Linux CKD DASD migration from one DASD Subsystem to another

[Tom Duerbusch]

And if I remember correctly, when Mark joined Novell, we had this little 2 GB 
memory problem in VM.  That would force many large zLinux shops to have 
production running in LPARs.  They could still leave test and smaller zLinux 
images under z/VM.  

But the 2 GB line is no longer much of a problem.

Tom Duerbusch
THD Consulting

>>> David Boyes  1/22/2009 3:07 PM >>>
On 1/21/09 5:09 PM, "Mark Post"  wrote:

 On 1/21/2009 at  2:31 PM, David Boyes  wrote:
> -snip-
>> If I haven't said it before, I don't think there's much reason to ever
>> consider LPAR deployment of Linux, but others do disagree with that view.
>> I'm sure there are workloads where it would matter, but I still think the
>> manageability loss dramatically overwhelms any cost advantage from omitting
>> VM.
>
> When I first joined Novell, I was surprised to learn that the world's largest
> implementation was done all in LPARs.  From what I was told, that wasn't
> because of the dollar cost of z/VM, but the overhead.  Given the number of
> processors running, I could (somewhat) understand that, but to me that says
> that "people time is free" is the attitude, and that leads to another whole
> set of problems.

True enough. There's always exceptions, but they are just that: exceptions.
Right tool, right job, and LPAR is only rarely the right tool to make Linux
on Z interesting.

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

Re: Z/Linux CKD DASD migration from one DASD Subsystem to another

[Alan Altmark]

On Friday, 01/23/2009 at 03:23 EST, Marcy Cortes
 wrote:
> Alan wrote:
> >Iffen I had my druthers, I'druther SYSTEM CONFIG allowed volumes to be
> specified by device address instead of, or in addition to, volser.
>
> Ewww.  That'd suck for disaster recovery and PPRC Hyperswap.

Convenience and Security are rarely bedfellows.  Hopefully you use a
different system ID when you're in DR.  Use it to qualify the
OFFLINE/ONLINE_AT_IPL so that you get the correct address range depending
whether you are at home or abroad.

Alan Altmark
z/VM Development
IBM Endicott

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

Re: Z/Linux CKD DASD migration from one DASD Subsystem to another

[Pat Carroll]

>> Iffen I had my druthers, I'druther SYSTEM CONFIG allowed volumes to
be specified by device address instead of, or >> >> inaddition to,
volser.

Alan,
I see your point, but many would have an issue with that approach - many
DR scenarios would be at risk.
Pat

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

Re: Z/Linux CKD DASD migration from one DASD Subsystem to another

[Marcy Cortes]

Alan wrote:
>Iffen I had my druthers, I'druther SYSTEM CONFIG allowed volumes to be
specified by device address instead of, or in addition to, volser.  

Ewww.  That'd suck for disaster recovery and PPRC Hyperswap.

:)

Marcy

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

Re: Z/Linux CKD DASD migration from one DASD Subsystem to another

[Alan Altmark]

On Friday, 01/23/2009 at 07:58 EST, Clovis Pereira 
wrote:
> To avoid this risk doesn't put all these disks on SYSTEM CONFIG.
> If you need repeated volsers, is secure to use fullpack dasd defined as
> MDISK ... DEVNO. VM mounts them only when necessary  and volser doesn't
> matter
> I know a VM system that process many Disaster Recovery tests
> simultaneously, where many customers keep your dasds as 530RES by
example.
> Use of DEVNO keep all secure and independent. Of course, the owned dasds
> have another different volsers and was mounted at lowest addresses.
> MVS doesn't work this way, so these dasds must be defined as OFFLINE to
> other MVS LPARs.

Commandments 11 and 12 still apply.  DEVNO will not protect you as it is
simply a way to give a guest a full-pack minidisk without regard to the
volser.  If the guest changes the volser to match a volser that is listed
in SYSTEM CONFIG, then you are at risk on the next IPL.

Do not depend on the lowest-address-wins algorithm.  That was a way to
ensure a determinate result at IPL, not a way to protect the system from
duplicate volsers.  What would happen if one of your low-address volumes
is offline for some reason?  Answer: CP will pick the next one.  And if
the system comes up, it may well overwrite user data on the volume.

Iffen I had my druthers, I'druther SYSTEM CONFIG allowed volumes to be
specified by device address instead of, or in addition to, volser.  ("Odd,
my checkpoint area doesn't have the same volser today.")

Alan Altmark
z/VM Development
IBM Endicott

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

Re: Filesystems linux under ZVM

[Shawn Wells]

John Summerfield wrote:

Hugo Luis Vitelli wrote:

Excuse David .. if I do not speak well ... the truth is that I have to
install a zVM in Suse Linux 5.3 and wanted to consult because they have
more experience if I could show the best way to configure the file
system,
if I install in a disk or distribute in minidisks.



It would also helped if you checked what distribution and release you
have on hand.

SUSE5.x is really really old (if it ever exist), SUSE is up to 10 now.
OTOH Red Hat has just announced Red Hat Enterprise Linux 5.3 (the latest
update of RHEL5), but I don't recall that the announcement mentioned
zSeries.


Only FYI (I've actually gotten a *ton* of questions about this, in case
anyone here is wondering) -- we don't do individual releases by
architecture.  When we GA, it's for all platforms.

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

Re: bonding multiple qeth vnics to vswitch?

[Alan Altmark]

On Friday, 01/23/2009 at 01:30 EST, Mark Post  wrote:
> > Then this must be a Layer 3 VSWITCH where we don't care about or use
guest
> > MACs.  A Layer 2 VSWITCH (required for LACP) enforces unique MACs.
>
> Nope, it's Layer 2.  If I tried to use a Layer 3, it didn't work.  (It
would
> appear to, but the system wouldn't think there was a link established.)
It may
> be that the MAC is viewed as being the same by the kernel, but the
VSWITCH
> doesn't modify it's control blocks to match.

A mystery indeed.  As Pieter suggested, seeing the output of QUERY NIC
DETAILS would be edifying.

Alan Altmark
z/VM Development
IBM Endicott

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

Re: bonding multiple qeth vnics to vswitch?

[Mark Post]

>>> On 1/23/2009 at  1:24 PM, Alan Altmark  wrote: 
> On Friday, 01/23/2009 at 10:54 EST, Mark Post  wrote:
-snip-
>> When the bonded NIC starts up, both of the slave's MAC addresses are set
> to be
>> the same.  So, they're not unique.
> 
> Then this must be a Layer 3 VSWITCH where we don't care about or use guest
> MACs.  A Layer 2 VSWITCH (required for LACP) enforces unique MACs.

Nope, it's Layer 2.  If I tried to use a Layer 3, it didn't work.  (It would 
appear to, but the system wouldn't think there was a link established.)  It may 
be that the MAC is viewed as being the same by the kernel, but the VSWITCH 
doesn't modify it's control blocks to match.


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

Re: bonding multiple qeth vnics to vswitch?

[Alan Altmark]

On Friday, 01/23/2009 at 10:54 EST, Mark Post  wrote:
> >>> On 1/22/2009 at  6:51 PM, Alan Altmark 
wrote:
> -snip-
> > While you can have multiple vNICs on an aggregating VSWITCH, there's
> > nothing that will spray/deal queued frames across the vNICs since they
> > each have a unique MAC address.
>
> When the bonded NIC starts up, both of the slave's MAC addresses are set
to be
> the same.  So, they're not unique.

Then this must be a Layer 3 VSWITCH where we don't care about or use guest
MACs.  A Layer 2 VSWITCH (required for LACP) enforces unique MACs.

Alan Altmark
z/VM Development
IBM Endicott

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

Re: bonding multiple qeth vnics to vswitch?

[Marcy Cortes]

Thanks!  Saves me some looking (and finding the stuff that doesn't work
:)
I'm going to consult with my network guy and see which he advises for
our case. 


Marcy 
 
"This message may contain confidential and/or privileged information. If
you are not the addressee or authorized to receive this for the
addressee, you must not use, copy, disclose, or take any action based on
this message or any information herein. If you have received this
message in error, please advise the sender immediately by reply e-mail
and delete this message. Thank you for your cooperation."


-Original Message-
From: Linux on 390 Port [mailto:linux-...@vm.marist.edu] On Behalf Of
Mark Post
Sent: Friday, January 23, 2009 9:04 AM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: [LINUX-390] bonding multiple qeth vnics to vswitch?

>>> On 1/23/2009 at 11:32 AM, Marcy Cortes
 wrote: 
-snip-
> Now... To figure out how to try the balanced mode.

I put "options bonding mode=?" in /etc/modprobe.conf.local for my
testing.  Be careful, though.  Some of the examples I ran across on the
'net showed this (which didn't work):
alias bond0 bonding
options bond0 mode=


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

Re: bonding multiple qeth vnics to vswitch?

[Mark Post]

>>> On 1/23/2009 at 11:32 AM, Marcy Cortes  
>>> wrote: 
-snip-
> Now... To figure out how to try the balanced mode.

I put "options bonding mode=?" in /etc/modprobe.conf.local for my testing.  Be 
careful, though.  Some of the examples I ran across on the 'net showed this 
(which didn't work):
alias bond0 bonding
options bond0 mode=


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

Re: bonding multiple qeth vnics to vswitch?

[Marcy Cortes]

Oh, you are right! (as usual :)

# cat /proc/net/bonding/bond0
Ethernet Channel Bonding Driver: v3.0.3 (March 23, 2006)

Bonding Mode: fault-tolerance (active-backup)
Primary Slave: None
Currently Active Slave: eth0
MII Status: up
MII Polling Interval (ms): 1
Up Delay (ms): 0
Down Delay (ms): 0

Slave Interface: eth0
MII Status: up
Link Failure Count: 0
Permanent HW addr: 02:00:00:00:00:41

Slave Interface: eth1
MII Status: up
Link Failure Count: 0
Permanent HW addr: 02:00:00:00:00:42 

Now... To figure out how to try the balanced mode.

Marcy 

"This message may contain confidential and/or privileged information. If
you are not the addressee or authorized to receive this for the
addressee, you must not use, copy, disclose, or take any action based on
this message or any information herein. If you have received this
message in error, please advise the sender immediately by reply e-mail
and delete this message. Thank you for your cooperation."


-Original Message-
From: Linux on 390 Port [mailto:linux-...@vm.marist.edu] On Behalf Of
Mark Post
Sent: Friday, January 23, 2009 8:06 AM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: [LINUX-390] bonding multiple qeth vnics to vswitch?

>>> On 1/23/2009 at 10:59 AM, Marcy Cortes
 wrote: 
> Right,
> 
> And not sure if it would help Pieter's problem anyway:

It didn't seem to, no.

-snip-
> Given the counts, it seems to greatly favor one over the other (this 
> one is sles 10 sp2)

That looks more like mode 1 than mode 0 or 2.  When I did my (brief)
testing, the TX bytes (not packets oddly) were very close.


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

Re: Security question and using scp

[Larry Ploetz]

On 1/22/09 4:38 PM, John Summerfield wrote:

Larry Ploetz wrote:

Scott Rohling _/*DID NOT*/_ wrote:


If I must configure bind, maybe I need a text editor. If I can use a
text editor maybe I can edit /etc/sudoers

I said that


That's what sudoedit (not visudoers!) is for.


The point is that I can actually use any editor I like, so long as I get
it right. I have actually used at least one of ed, ex and sed, I edit it
in my kickstart %post section.



I may very well be missing the point entirely, but am trying to point 
out that if anyone needs to be able to edit system (or other users') 
configuration files, but should not become root to do so (so they can't 
use shell escapes to run any command as root), sudoedit securely makes a 
copy of the file(s) the sudo user is allowed to edit into /tmp, runs the 
sudo user's editor-of-choice as the sudo user with no escalated 
privileges, checks to see if any changes were made and if so, securely 
copies the file back to the correct place -- no exposure WRT file 
maintenance (of course, if you allow someone to sudoedit /etc/passwd, 
/etc/shadow or /etc/sudoers you've got a Gaping Hole©, but that's not 
sudoedit's fault, that's yours). Assuming sudo is properly configured to 
allow the sudo user to run sudoedit, on the file(s) that user is 
specifically allowed to edit (e.g., bind configuration).

--

  
*

Larry Ploetz
Systems Administrator
Carnegie Institution of Washington
Department of Plant Biology
The Arabidopsis Information Resource
650 325 1521 x 296 la...@tairgroup.org *

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

New Whitepaper available:: Tuning WebSphere Application Server Cluster with Caching

[Dorothea Matthaeus]

Tuning WebSphere Application Server Cluster with Caching

The paper is available at:

   TecDocs:
   http://www-03.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/WP101406
   developerWorks:
   
http://www-128.ibm.com/developerworks/linux/linux390/perf/tuning_pap_websphere.html#wascc

This paper analyzes parameter and configuration variations in a WebSphere®
Application Server cluster running the Trade workload when caching is
enabled. A secure environment was used  with a DMZ to protect the
application servers against an uncontrolled external zone.

The  findings include:
   Any form for caching resulted in a significant throughput improvement
   over the no caching case, where Distributed map caching gave in the
   highest throughput improvement.
   Dynachache disk-off load can significantly improve the performance with
   small caches without additional CPU cost.
   The z/VM® VSWITCH LAN configuration resulted in higher throughput than
   the Guest LAN feature.
   The IBM® System z10® system obtained a significant throughput advantage
   over the IBM® System z9® system
   They highly recommend z/VM for environments like this.


Dorothea Matthaeus
Linux on System z Information Development
IBM Deutschland Entwicklung GmbH
--
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

Re: bonding multiple qeth vnics to vswitch?

[Harder, Pieter]

For comparison have a look at cp q nic details and note the difference between 
Adapter MAC and Unicast MAC
Anyway, I have set up a production test for tonight that will transfer on the 
order of 2-3 TB with about 100 clients. We'll see what will happen there both 
balance and performance wise.

Best regards,
Pieter Harder

pieter.har...@brabantwater.nl
tel  +31-73-6837133 / +31-6-47272537


-Oorspronkelijk bericht-
Van: Linux on 390 Port [mailto:linux-...@vm.marist.edu] Namens Marcy Cortes
Verzonden: vrijdag 23 januari 2009 16:59
Aan: LINUX-390@VM.MARIST.EDU
Onderwerp: Re: bonding multiple qeth vnics to vswitch?

Right,

And not sure if it would help Pieter's problem anyway:

 # ifconfig
bond0 Link encap:Ethernet  HWaddr 02:00:00:00:00:41
  inet addr:10.93.27.250  Bcast:10.93.27.255  Mask:255.255.255.0
  inet6 addr: fe80::ff:fe00:41/64 Scope:Link
  UP BROADCAST RUNNING MASTER MULTICAST  MTU:1500  Metric:1
  RX packets:412326 errors:0 dropped:0 overruns:0 frame:0
  TX packets:513783 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:0
  RX bytes:115082811 (109.7 Mb)  TX bytes:127188062 (121.2 Mb)

eth0  Link encap:Ethernet  HWaddr 02:00:00:00:00:41
  UP BROADCAST RUNNING SLAVE MULTICAST  MTU:1500  Metric:1
  RX packets:394205 errors:0 dropped:0 overruns:0 frame:0
  TX packets:513781 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:1000
  RX bytes:114199553 (108.9 Mb)  TX bytes:127187894 (121.2 Mb)

eth1  Link encap:Ethernet  HWaddr 02:00:00:00:00:41
  UP BROADCAST RUNNING SLAVE MULTICAST  MTU:1500  Metric:1
  RX packets:18121 errors:0 dropped:0 overruns:0 frame:0
  TX packets:2 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:1000
  RX bytes:883258 (862.5 Kb)  TX bytes:168 (168.0 b)

loLink encap:Local Loopback
  inet addr:127.0.0.1  Mask:255.0.0.0
  inet6 addr: ::1/128 Scope:Host
  UP LOOPBACK RUNNING  MTU:16436  Metric:1
  RX packets:198 errors:0 dropped:0 overruns:0 frame:0
  TX packets:198 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:0
  RX bytes:11715 (11.4 Kb)  TX bytes:11715 (11.4 Kb)

Given the counts, it seems to greatly favor one over the other (this one
is sles 10 sp2)


Marcy
"This message may contain confidential and/or privileged information. If
you are not the addressee or authorized to receive this for the
addressee, you must not use, copy, disclose, or take any action based on
this message or any information herein. If you have received this
message in error, please advise the sender immediately by reply e-mail
and delete this message. Thank you for your cooperation."


-Original Message-
From: Linux on 390 Port [mailto:linux-...@vm.marist.edu] On Behalf Of
Mark Post
Sent: Friday, January 23, 2009 7:53 AM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: [LINUX-390] bonding multiple qeth vnics to vswitch?

>>> On 1/22/2009 at  6:51 PM, Alan Altmark 
wrote:
-snip-
> While you can have multiple vNICs on an aggregating VSWITCH, there's
> nothing that will spray/deal queued frames across the vNICs since they

> each have a unique MAC address.

When the bonded NIC starts up, both of the slave's MAC addresses are set
to be the same.  So, they're not unique.


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

Brabant Water N.V.
Postbus 1068
5200 BC  's-Hertogenbosch
http://www.brabantwater.nl
Handelsregister: 16005077

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

Re: bonding multiple qeth vnics to vswitch?

[Mark Post]

>>> On 1/23/2009 at 10:59 AM, Marcy Cortes  
>>> wrote: 
> Right,
> 
> And not sure if it would help Pieter's problem anyway:

It didn't seem to, no.

-snip-
> Given the counts, it seems to greatly favor one over the other (this one
> is sles 10 sp2)

That looks more like mode 1 than mode 0 or 2.  When I did my (brief) testing, 
the TX bytes (not packets oddly) were very close.


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

Re: bonding multiple qeth vnics to vswitch?

[Marcy Cortes]

Right,

And not sure if it would help Pieter's problem anyway:

 # ifconfig
bond0 Link encap:Ethernet  HWaddr 02:00:00:00:00:41
  inet addr:10.93.27.250  Bcast:10.93.27.255  Mask:255.255.255.0
  inet6 addr: fe80::ff:fe00:41/64 Scope:Link
  UP BROADCAST RUNNING MASTER MULTICAST  MTU:1500  Metric:1
  RX packets:412326 errors:0 dropped:0 overruns:0 frame:0
  TX packets:513783 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:0
  RX bytes:115082811 (109.7 Mb)  TX bytes:127188062 (121.2 Mb)

eth0  Link encap:Ethernet  HWaddr 02:00:00:00:00:41
  UP BROADCAST RUNNING SLAVE MULTICAST  MTU:1500  Metric:1
  RX packets:394205 errors:0 dropped:0 overruns:0 frame:0
  TX packets:513781 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:1000
  RX bytes:114199553 (108.9 Mb)  TX bytes:127187894 (121.2 Mb)

eth1  Link encap:Ethernet  HWaddr 02:00:00:00:00:41
  UP BROADCAST RUNNING SLAVE MULTICAST  MTU:1500  Metric:1
  RX packets:18121 errors:0 dropped:0 overruns:0 frame:0
  TX packets:2 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:1000
  RX bytes:883258 (862.5 Kb)  TX bytes:168 (168.0 b)

loLink encap:Local Loopback
  inet addr:127.0.0.1  Mask:255.0.0.0
  inet6 addr: ::1/128 Scope:Host
  UP LOOPBACK RUNNING  MTU:16436  Metric:1
  RX packets:198 errors:0 dropped:0 overruns:0 frame:0
  TX packets:198 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:0
  RX bytes:11715 (11.4 Kb)  TX bytes:11715 (11.4 Kb) 

Given the counts, it seems to greatly favor one over the other (this one
is sles 10 sp2)


Marcy  
"This message may contain confidential and/or privileged information. If
you are not the addressee or authorized to receive this for the
addressee, you must not use, copy, disclose, or take any action based on
this message or any information herein. If you have received this
message in error, please advise the sender immediately by reply e-mail
and delete this message. Thank you for your cooperation."


-Original Message-
From: Linux on 390 Port [mailto:linux-...@vm.marist.edu] On Behalf Of
Mark Post
Sent: Friday, January 23, 2009 7:53 AM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: [LINUX-390] bonding multiple qeth vnics to vswitch?

>>> On 1/22/2009 at  6:51 PM, Alan Altmark 
wrote: 
-snip-
> While you can have multiple vNICs on an aggregating VSWITCH, there's 
> nothing that will spray/deal queued frames across the vNICs since they

> each have a unique MAC address.

When the bonded NIC starts up, both of the slave's MAC addresses are set
to be the same.  So, they're not unique.


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

Re: bonding multiple qeth vnics to vswitch?

[Mark Post]

>>> On 1/22/2009 at  6:51 PM, Alan Altmark  wrote: 
-snip-
> While you can have multiple vNICs on an aggregating VSWITCH, there's
> nothing that will spray/deal queued frames across the vNICs since they
> each have a unique MAC address.

When the bonded NIC starts up, both of the slave's MAC addresses are set to be 
the same.  So, they're not unique.


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

Re: bonding multiple qeth vnics to vswitch?

[Mark Post]

>>> On 1/22/2009 at  6:09 PM, "Harder, Pieter" 
wrote: 
-snip-
> That is strange. Mode 1 is active-backup, where by definition only one nic is 
> active.

That was a typo on my part.  I meant I tried both mode 0 and mode 2.  Again, 
the results were outgoing traffic was balanced, incoming not (as I would 
expect).


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

Re: bonding multiple qeth vnics to vswitch?

[Marcy Cortes]

The reasons Alan lists are the reasons we went LACP.  With Guest Lan, we
were lighting up 4 osa ports.  We were concerned about sending all the
traffic over 1.  And OSA failures (and they do fail) result in a pause
to switch over to the backup vswitch port.   We have an app that doesn't
like tiny dramatic pauses (lots of folks get paged).   Our next step is
VSS in the cisco switch to eliminate switch failures from causing the
pause and the switch to the 1 (backup) interface.

We explored using channel bonding briefly to have a guest's traffic over
2 interfaces.   We are using channel bonding for an app that can't use
vswitch, but all the other servers do use the lacp vswitch.

But it won't solve your problem Pieter it sounds like.  Sounds more like
a capacity issue.


Marcy 
 
"This message may contain confidential and/or privileged information. If
you are not the addressee or authorized to receive this for the
addressee, you must not use, copy, disclose, or take any action based on
this message or any information herein. If you have received this
message in error, please advise the sender immediately by reply e-mail
and delete this message. Thank you for your cooperation."


-Original Message-
From: Linux on 390 Port [mailto:linux-...@vm.marist.edu] On Behalf Of
Alan Altmark
Sent: Thursday, January 22, 2009 3:52 PM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: [LINUX-390] bonding multiple qeth vnics to vswitch?

On Thursday, 01/22/2009 at 05:05 EST, "Harder, Pieter"
 wrote:
> You just lost me. LACP is on the trunk side of the VSWITCH. I am 
> talking

> bonding on the port side of it. What exactly did you think of doing 
> that
was
> solved by LACP?

Talk about a confusing conversation!

For those who left their scorecard at home today, LACP (Link Aggregation
Control Protocol) support in the VSWITCH is directed only at the
physical switch.  The guest-facing side of the VSWITCH does not support
LACP.
(Let's avoid terms like "port side" and "trunk side".  When a guest is
using a virtual trunk, which side is the "trunk side"?)  LACP is the
thing that lets the host and switch coordinate traffic.

The only use of LACP that I've seen/heard about so far is for better
error toleration and recovery, better physical OSA management
(dynamically delete from group so you can put on microcode fixes, then
re-add), and to satisfy Management demand to "Stop wasting OSAs!  Why
aren't both LEDs flickering?!?  I'm not paying for LEDs that don't
flicker!"  (FYI, IEEE 802.3ad spec lists 9 benefits of which increased
bandwidth is only one.)

While you can have multiple vNICs on an aggregating VSWITCH, there's
nothing that will spray/deal queued frames across the vNICs since they
each have a unique MAC address.  But even if it did, you're doomed if
the buffer fill rate is higher than the consumption rate.  All you've
done is delay slightly the point at which all guest buffers are full.

Alan Altmark
z/VM Development
IBM Endicott

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

Re: XIP (Execute In Place) for z/Linux running with RedHat 4.6

[Shawn Wells]

Martin, Terry R. (CMS/CTR) (CTR) wrote:

Hi



I am looking into XIP and I am wondering someone can share their
experiences in terms of setting up XIP and actually running with it.
Also does RedHat 4.6 support XIP?



Thanks,



Terry


Check out "How to use Execute-in-Place Technology with Linux on z/VM,
SC33-8283-00, March 23, 2005" available at
http://awlinux1.alphaworks.ibm.com/developerworks/linux390/docu/l26bhe00.pdf

Also p166 of the RHEL4 cookbook at
http://linuxvm.org/Present/misc/virt-cookbook-1.pdf, "Creating a
DCSS/XIP2 shared file system"

-Shawn

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

Re: Z/Linux CKD DASD migration from one DASD Subsystem to another

[Clovis Pereira]

To avoid this risk doesn't put all these disks on SYSTEM CONFIG.
If you need repeated volsers, is secure to use fullpack dasd defined as
MDISK ... DEVNO. VM mounts them only when necessary  and volser doesn't
matter
I know a VM system that process many Disaster Recovery tests
simultaneously, where many customers keep your dasds as 530RES by example.
Use of DEVNO keep all secure and independent. Of course, the owned dasds
have another different volsers and was mounted at lowest addresses.
MVS doesn't work this way, so these dasds must be defined as OFFLINE to
other MVS LPARs.
Regards, Clovis



   
 Alan Altmark  
To
 Sent by: Linux on LINUX-390@VM.MARIST.EDU 
 390 Port   cc
   Subject
   Re: Z/Linux CKD DASD migration from
   one DASD Subsystem to another   
 21/01/2009 18:31  
   
   
 Please respond to 
 Linux on 390 Port 
   
   
   




On Wednesday, 01/21/2009 at 02:39 EST, David Boyes 
wrote:
> I also really prefer to let VM manage the actual cyl 0. That may be just
> that I'm ancient and weird, but that way, there's absolutely zero chance
> that something weird in Linux will cause something unpleasant to happen
to a
> disk that some other OS cares about, and there's zero chance of some
yoyo
> creating duplicate volids on the physical system, which could impact the
> operation of the entire environment (cf the discussion about what order
> multiple DRCT areas get interpreted if you want to see how random that
can
> get)

z/VM presumes that you do not have any duplicate volids for any volid that
appears in SYSTEM CONFIG.  If you allow duplicate volids, then you place
the system at risk since the system may mount the wrong volume during IPL.


:
11.  Thou shalt Not give cylinder 0 unto thine untrusted guests
12.  Thou may ignorest #11 if thou will use OFFLINE_AT_IPL and
ONLINE_AT_IPL to ensure that only the RDEVs desired by thee are processed
in SYSTEM CONFIG.

Let not the serpent of Convenience sway you onto a Dark path of
Corruption.

Alan Altmark
z/VM Development
IBM Endicott

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

<><><>

Re: Z/Linux CKD DASD migration from one DASD Subsystem to another

[Clovis Pereira]

For who have DIRMAINT enabled and properly configured (file EXTENT CONTROL,
at least), the steps 1-5, 7 and 9 can be substituted by a unique command:
DIRM CMD (ChangeMDisk).
The step 6 can be started as a batch of commands, using several CMD
commands; see DIRM BATCH.
Full packs can be managed the same way, if defined as MDISK ... DEVNO,
Doesn't work for DEDICATEd dasds.
And the command DIRM CLONED can be used to duplicate MDISK: alloc, define
and populate (even if fullpacks with DEVNO).
Commands very useful.
Regards, Clovis.



   
 David Boyes   
  To
 Sent by: Linux on LINUX-390@VM.MARIST.EDU 
 390 Port   cc
   Subject
   Re: Z/Linux CKD DASD migration from
   one DASD Subsystem to another   
 21/01/2009 16:42  
   
   
 Please respond to 
 Linux on 390 Port 
   
   
   




On 1/21/09 12:02 PM, "tony...@bellsouth.net"  wrote:

> Hi all,
> I would like to know what ways you have used to migrate z/Linux CKD DASD
> volumes from one DASD subsystem to another?  Thanks.

If you used minidisks (the right way, IMHO) then you:

1) Allocate new minidisks on the new array using a knowable pattern, eg if
you have a 150 on the existing guest, allocate a new minidisk at F150 on
the
userid. Do this for all the minidisks on that userid.

2) Shut the guest down. You need to do this to get a good copy.

3) From an appropriately privileged ID (MAINT, etc):

LINK guest 150 150 RR  (you don't need/want write access to this
volume)
LINK guest F150 F150 MR(you're going to overwrite this one, so write)

4) DDR the contents of one to the other:

DDR
SYSPRINT CONS
INPUT 150 3390 SCRTCH
OUTPUT F150 3390 SCRTCH
COPY ALL


5) DETACH 150
   DETACH F150

6) Repeat #3 and #4 for all the other minidisks for that userid.

7) Update the CP directory and swap the MDISK definitions for the 150 and
F150 MDISKs (make the old one F150, and the new one 150). Repeat for all
minidisks on that userid. Write the CP directory either by hand or using
your directory manager. If you want, you can just comment the old disks out
in the directory entry in case you need to switch back for some reason.

8) IPL the guest as normal. That id is now running on the new disks.

9) Deallocate the Fxxx disks. If you commented them out in step 8, they are
now free disk space until you overwrite them or reallocate the space.

10) Repeat for all guests.

If you used dedicated volumes, now you pay for it. There is a procedure on
linuxvm.org to do this -- you get to do it the hard way.

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

<><><>

Re: bonding multiple qeth vnics to vswitch?

[Harder, Pieter]

>The guest-facing side of the VSWITCH does not support LACP.
>(Let's avoid terms like "port side" and "trunk side".  When a guest is
>using a virtual trunk, which side is the "trunk side"?)  LACP is the thing
>that lets the host and switch coordinate traffic.

Ok, that's a better terminology, guest-facing and host-facing side. I got my 
wording from our Cisco people, but they live in a different world :-)

>The only use of LACP that I've seen/heard about so far is for better error
>toleration and recovery, better physical OSA management (dynamically
>delete from group so you can put on microcode fixes, then re-add),

Yes, a really usefull capability. That's why I moved all my GbEs to VSWITCH. I 
really wouldn't like to take some out again.

>While you can have multiple vNICs on an aggregating VSWITCH, there's
>nothing that will spray/deal queued frames across the vNICs since they
each have a unique MAC address.

Alan, can you comment on what may have happened to the test Mark ran with 
bonding mode 2? Would it really behave like bonding mode 1? It sounded like it 
worked (well, gave no errors in setting up), but do you expect it to accomplish 
something usefull?

>But even if it did, you're doomed if the
>buffer fill rate is higher than the consumption rate.  All you've done is
>delay slightly the point at which all guest buffers are full.

Of course you can't fill more than you consume. But with more buffers you can 
consume in larger batches, then turn to other work or fall asleep. This will 
make you more Q3 instead of Q1, which is more efficient for large transfers.

Best regards,
Pieter Harder

pieter.har...@brabantwater.nl
tel  +31-73-6837133 / +31-6-47272537

Brabant Water N.V.
Postbus 1068
5200 BC  's-Hertogenbosch
http://www.brabantwater.nl
Handelsregister: 16005077

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