Cornelia - thank you for your reply.
I am working from the Redbook: Virtualization Cookbook ... Volume 1 and
am finding typos in it. In this case the cio_ignore command was botched
up and included in the description before a set of steps to configure
hipersockets on RH. it should have been step nu
On Fri, 13 Jul 2018 14:38:44 -0500
Phillip Gramly wrote:
I'm seconding the suggestion of using chzdev, but some additional notes
from me:
> # vmcp q v 204-206
> OSA 0204 ON NIC 0204 UNIT 000 SUBCHANNEL = 0001
> 0204 DEVTYPE HIPER VIRTUAL CHPID 01 IQD
> 0204 MAC 02-00-00-00-00-
The chzdev command also simplifies things. It's part of s390utils-base.
On 7/14/18, 06:38, "Linux on 390 Port on behalf of R P Herrold"
wrote:
On Fri, 13 Jul 2018, Phillip Gramly wrote:
> # echo 0.0.204,0.0.205,0.0.206 > /sys/bus/ccwgroup/drivers/qeth/group
> -bash: echo: writ
On Fri, 13 Jul 2018, Phillip Gramly wrote:
> # echo 0.0.204,0.0.205,0.0.206 > /sys/bus/ccwgroup/drivers/qeth/group
> -bash: echo: write error: Invalid argument
>
> I'm missing something somewhere. can anybody help me?
Hi, Phillip,
Thanks for using ClefOS
1. This is just my OCD talking, but I w
I have my ClefOS system up which i initially brought up connected to
our VSWITCH (this is under zVM 6.3)
i want to set up Hipersockets using a guest LAN.
i used :
CP DEFINE LAN ZVTSMLAN OWNERID SYSTEM TYPE HIPER IP MFS 64K
and was able to connect to it from a VSE system.
Now i am
t; not the IOPs.
>
>
Anything that moves packets will cost CPU cycles, in the Linux TCP/IP stack
and in CP. The biggest factor is the number of packets, so 56K packets on
HiperSockets is hard to beat in comparison with 1500 byte on the LAN. A
virtual NIC (connected to a VSWITCH or Guest LAN) is so
On Tuesday, 07/17/2012 at 11:34 EDT, "Norris, Chet"
wrote:
> It sounds like Alan's "HiperSocket VSWITCH Bridge" could be an option,
but
> multiple people (including Alan) have recommended using direct
Hipersocket
> device definitions for each zLinux user.
Perhaps there is a misunderstanding. I h
I guess my main drive to use a common guest LAN was to avoid having to assign a
unique device set for each zLinux guest by specifying a SPECIAL definition in
each. The main use for the Hipersocket connections would be to run zLinux
backup/restore processing based on the MVS platform, and I
On Monday, 07/16/2012 at 10:51 EDT, Shane G wrote:
> On Tue, Jul 17th, 2012 at 6:37 AM, Alan Altmark wrote:
> ...
> > TCPIP is connected to two HiperSocket networks: one real (to MVS) and
one
> > virtual (to Linux).
>
> Now, hold it right there fella. I want the order number for one of those
> *re
On Tue, Jul 17th, 2012 at 6:37 AM, Alan Altmark wrote:
...
> TCPIP is connected to two HiperSocket networks: one real (to MVS) and one
> virtual (to Linux).
Now, hold it right there fella. I want the order number for one of those
*real* hipersockets.
(haven't we been here before ... ;-)
Shane ...
On Monday, 07/16/2012 at 09:44 EDT, Mark Post wrote:
> Alternatively, he could just attach a real HiperSocket device to the
Linux
> system and cut out the middle man (z/VM TCPIP) entirely. Unless there's
some
> value to be had by having z/VM manage the traffic, it's just unnecessary
> overhead.
>>> On 7/16/2012 at 04:37 PM, Alan Altmark wrote:
> TCPIP is connected to two HiperSocket networks: one real (to MVS) and one
> virtual (to Linux). So TCPIP will need two HiperSocket interfaces, each
> with it's own IP address in each of the two networks. You have the real
> one (5.1.1.1), but
On Monday, 07/16/2012 at 02:38 EDT, "Norris, Chet"
wrote:
> I'm not able to get any response back to my zlinux guest over a guest
LAN I've
> set up for Hipersocket connections.
>
> I've defined IP/ADDR 5.1.1.1 as a VM home address, 5.1.1.3 as the MVS
home and
On Mon, Jul 16, 2012 at 04:59:49PM +, Norris, Chet wrote:
> I've defined IP/ADDR 5.1.1.1 as a VM home address, 5.1.1.3 as the MVS home
> and set up the Linux guest as 5.1.2.10.
It would be preferable if you could use RFC 1918 allocations for your legacy IP
interconnections. Just using random I
I'm not able to get any response back to my zlinux guest over a guest LAN I've
set up for Hipersocket connections.
I've defined IP/ADDR 5.1.1.1 as a VM home address, 5.1.1.3 as the MVS home and
set up the Linux guest as 5.1.2.10.
A static route for 5.1.2.0/24 has been defined und
Yes - doing this either in the PROFILE EXEC or the directory would eliminate
the issue... we were trying to get it working dynamically before we
'hardcoded it' ;-) So this is just a gotcha for dynamic
define/coupling... Thanks for your post!
Scott
On Tue, Aug 11, 2009 at 2:18 PM, Steffen M
On 08/11/2009 04:54 PM, Brad Hinson wrote:
> As to why layer3/IP mode isn't working, it could be my setup, but I
> noticed this on the console when I brought the nic online with echo 1 >
> /sys/bus/...:
>
> HCPIPN2833E Error 'E00A'X adding IP address 192.168.7.3 for VSWITCH
> SYSTEM VSW2.
> HCPIPN
On 08/11/2009 08:31 PM, Scott Rohling wrote:
> #CP DEFINE NIC 900 TYPE QDIO#CP COUPLE 900 GUESTA MYLAN
>
> eth2 came up automatically on Linux and once I did the above on both guests
> - it worked and I can ping using IP.
>
> So - can you 'stack' commands using the vmcp within Linux?
Hm, don't k
I got this working.. and the secret was eliminating the time between the
'define nic' and the 'couple'.. When I did the define nic - I saw messages
on the console that it recognized 900 as a QDIO, etc -- but failed to
register the IP address and some other messages.
So - I tried logging into t
I set this up and was unable to get it working at first, too. As a
test, I destroyed everything then recreated the GuestLAN with the 'eth'
keyword to test layer2. Then I added OPTIONS="layer2=1" and
MACADDR=<> to ifcfg-ethX. With the GuestLAN in layer2
mode, I can ping successfully.
As to why
We want to establish a small private subnet that some guests can use to
communicate with between themselves, with all ports open...
On guest A:
vmcp define lan mylan type qdio
vmcp define nic 900 type qdio
vmcp couple 900 to guesta mylan
We have an ifcfg-eth2 (this is redhat) that gives an addre
interface. In my previous post I tried to
describe the *bevhavior* as best I could.
> It looks like I need to give it more thought to determine just how many
> Linux guest will want hipersocket access to z/os data. It may not be
> worth the effort to configure a hipersocket guest lan for
riate interface much a like a router
supporting token ring and Ethernet.
It looks like I need to give it more thought to determine just how many
Linux guest will want hipersocket access to z/os data. It may not be
worth the effort to configure a hipersocket guest lan for the the Linux
gues
est profile and added the
> IUTIQDEF device to the OSPF config for MPROUTE (same subnet as the
> IUTIQDFF interface). We then created a new guest lan (glan01 with type
> hipersocket and used nicdef/couple commands for a Linux guest and the
> TCPIP guest to use that hipersocket guest lan
d vice versa? Particuarly before the
dynamic routing protocols attempt to figure things out. (And I doubt they'll
be very successful.)
> We then created a new guest lan (glan01 with type
> hipersocket and used nicdef/couple commands for a Linux guest and the
> TCPIP guest to use tha
/VM TCPIP guest profile and added the
IUTIQDEF device to the OSPF config for MPROUTE (same subnet as the
IUTIQDFF interface). We then created a new guest lan (glan01 with type
hipersocket and used nicdef/couple commands for a Linux guest and the
TCPIP guest to use that hipersocket guest lan.
The
I appreciate everyone's input. We are going to try to implement the
VSWITCH.
Thanks
Gene
Gene Walters
System Programmer
WV Dept of Administration - OT
304-558-5914 ext 8902
Fax 304-558-1351
>>> [EMAIL PROTECTED] 5/14/2007 1:42:51 PM >>>
> > If it were me, I'd probably go with the VSWITCH. Heart
> > If it were me, I'd probably go with the VSWITCH. Heartbeat packets
> > really don't exploit the best parts of real hipersockets (high
volume
> > bulk data transfer) much, and the ability to separate stuff easily
later
> > is a big architectural win in my book.
> >
> Makes sense, particularly in
If it were me, I'd probably go with the VSWITCH. Heartbeat packets
really don't exploit the best parts of real hipersockets (high volume
bulk data transfer) much, and the ability to separate stuff easily later
is a big architectural win in my book.
Makes sense, particularly in our case where we
> I have one z9 foot-print with two books. In one I run one zVM1 (CP1)
> and on the sencond, I run zVM2 (CP2). Under each zVM I run Linux
> guest servers. The fail-over for a given Linux guest is on the
> opposite zVM.
>
> My question, how should I set up the life-line between the fail-over
>
Check out http://www.zjournal.com/index.cfm?section=article&aid=315 "Planning and
Implementing VSWITCH for Linux/390 Guests." That should give you a good idea of what
the differences are.
I am still not certain on what we need to do but now I understand the
difference.
I have one z9 foot-p
>>> On Tue, May 8, 2007 at 1:36 PM, in message <[EMAIL PROTECTED]>, Gene
Walters <[EMAIL PROTECTED]> wrote:
-snip-
> We have Z/VM 5.1 running on an IFL and an OSA-Express card. What
> should we be using instead of CTC's for network connection, VGuest,
> VSwitch VLAN? I'm confused as to what eac
I'm confused as to what each actually does.
>
> Any help would be appreciated.
1. Guest LAN. A simulated LAN segment contained entirely within CP.
Connections to the Outside are done by using a "virtual router". That is,
a virtual machine that connects both to the Outside and t
Gene,
Yes, VSWITCH seems to be the most popular. We describe how to implement
it in a number of "Virtualization Cookbook"s on
http://linuxvm.org/present/. For z/VM 5.1 you have to manually define the
VSWITCH controllers. See:
http://linuxvm.org/present/misc/virt-cookbook-1.pdf
If you move up to
You should take a look at using vswitch. It lets you horizontally
extend your physical networks into a zvm guest lan without routing
on zvm. You're most of the way there sort of already with your osa
card.
Vswitch lets you have the same network defined on physical and virtual
hosts. No ro
M
Please respond to
Linux on 390 Port
To
LINUX-390@VM.MARIST.EDU
cc
Subject
Guest Lan/VSwitch/VLAN
Hi All,
I know this is a broad question, but I am trying to understand some
things.
We currently are using CTC connections for our network access to our
Linux Instances running under VM. W
Yep, that is the hard way, now a days.
Vswitch is the way to go. Much, much easier to setup and better performance
along with automatic fall over, being VERY easy to setup.
No longer will you be using your TCPIP stack on VM for routing packets to guest
OSs. The VM stack will only be used for
Hi All,
I know this is a broad question, but I am trying to understand some
things.
We currently are using CTC connections for our network access to our
Linux Instances running under VM. We were told that CTC's were doing it
the hard way. So I am trying to figure out what the other way is.
We
> Alan (or someone else) will correct me, but I'm pretty sure
> that with z/VM 4.3, all-zero MAC addresses were the way
> things worked. For a Guest LAN, it really doesn't make any
> difference. If this were a VSWITCH, that would be different.
All-zero MACs are n
Alan (or someone else) will correct me, but I'm pretty sure that with z/VM 4.3,
all-zero MAC addresses were the way things worked. For a Guest LAN, it really
doesn't make any difference. If this were a VSWITCH, that would be different.
Mark Post
-Original Message-
From: Li
Hello,
We are trying to setup guest Lan using QDIO and have carried out following
steps
GuestLan setup
DEFINE LAN GLAN1 TYPE QDIO
DEFINE NIC 1D00 TYPE QDIO
COUPLE 1D00 TO * GLAN1
ipl linux
echo ”qeth0,0x1d00,0x1d01,0x1d02" > /etc/chandev.conf
echo "add_parms,0x10,0x1d01,0x1
On Friday, 07/15/2005 at 01:05 EST, Alan Schilla
<[EMAIL PROTECTED]> wrote:
> I have been thinking about this and I'm sure my terminology is incorrect
but my
> intent is to isolate groups of hosts. Why would I use guest lan and need
a
> routing host whether it is zVM TCPIP o
I have been thinking about this and I'm sure my terminology is incorrect but my
intent is to isolate groups of hosts. Why would I use guest lan and need a
routing host whether it is zVM TCPIP or a Linux guest when with the
capabilities of VLAN and trunking I get the same result? Anyway I
I've got one SLES 7 guest left. kernel is 2.4.7-SuSE-SMP with a May 21,
2002 build date. Honestly, I use it so little that I can't remember what
the service is on it; however it's running just fine on the guest lan.
That being said, I'm sure you're correct. We really d
On Jul 11, 2005, at 10:40 AM, Little, Chris wrote:
All of them or none of them. It is unaware of a "guest lan" it
sees the
subnet. Whether real or virtual(ly real?) is irrelevant.
If it supports OSA, it doesn't matter. And I believe SUSE 7 on
(meaning all
versions pro
All of them or none of them. It is unaware of a "guest lan" it sees the
subnet. Whether real or virtual(ly real?) is irrelevant.
If it supports OSA, it doesn't matter. And I believe SUSE 7 on (meaning all
versions produced for 390/z hardware) have OSA support.
chris
-O
Hello,
Let me know the exact version of SuSE Linux which supports guest LAN.
Regards,
Neetu Jain
This document is classified as:
( ) L&T Infotech Proprietary & Confidential
( ) L&T Infotech Confidential
(x) L&T Infotech Internal Use Only
( ) General Business Information
( )
-Original Message-
From: Neetu Jain [mailto:[EMAIL PROTECTED]
Sent: Thursday, July 07, 2005 3:14 AM
To: LINUX-390@VM.MARIST.EDU
Subject: z/VM Guest LAN Setup Query !!
Hello,
We are having a MP3000 mainframe. We have installed z/VM 4.3 on one of
the LPARs. The SuSE Linux 7.0 with ker
ngarian Proverb
Gordon W. Wolfe, Ph.D. Boeing VM Enterprise Servers 425-865-5940
-Original Message-
From: Alan Altmark [mailto:[EMAIL PROTECTED]
Sent: Thursday, July 07, 2005 6:22 AM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: z/VM Guest LAN Setup Query !!
On Thursday, 07/07/2005 at 03:44Z
On Jul 7, 2005, at 5:14 AM, Neetu Jain wrote:
Can anybody explain the error in loading the driver and detailed
steps to
configure the Guest LAN on MP3000.
SLES 7 wouldn't work with Guest LANs until several patches into its
lifetime. Use a newer distribution.
d in setting up
> the Guest LAN.
Make sure you have the most "recent" 2.2.16 kernel and qeth module. I
don't know if you can still get SLES7 updates any more. See
http://www.ibm.com/developerworks/linux/linux390/current2_2.html for the
raw kernel patches and modules.
Also make
Hello,
We are having a MP3000 mainframe. We have installed z/VM 4.3 on one of
the LPARs. The SuSE Linux 7.0 with kernel (2.2.16) is installed on z/VM.
We are able to IPL the linux from z/VM. We are interested in setting up
the Guest LAN.
We have carried out the following steps:
1) Define a LAN
at works with SLES8. I have had some trouble cloning
SLES9
> from a guest lan master. I hope to get back to working with the SLES9
and I
> thought I would get the list thoughts.
Your terminology *is* a bit ambiguous. IEEE VLAN technology works on both
Guest LANs and Virtual Switches. It sou
contains multiple
vlan interfaces for default gateways. This allows me to separate production,
test, development, whatever servers and services into their own broadcast
domains. At least that works with SLES8. I have had some trouble cloning SLES9
from a guest lan master. I hope to get back to working
On 6/30/05, Alan Schilla <[EMAIL PROTECTED]> wrote:
> I will be converting a SLES9 zVM guest lan guest to VLAN in the near future
> and
Do you really mean what you say or do you have terminology mixed up?
VLAN is the technique to tag packets with a VLAN ID. Systems will only
see
I will be converting a SLES9 zVM guest lan guest to VLAN in the near future and
I was wondering if there are any specific steps I need to do to change the
definitions. I tried cloning a SLES9 guest lan master to a VLAN host a while
back and for some reason I could not get the VLAN active. The
Vic Cross wrote on 04/17/2005 09:22:27 AM:
> I ran the exact configuration (same Linux minidisks, same Guest LAN
config,
> same SYSTEM CONFIG, same machine/LPAR config) under z/VM 5.1 and
everything
> worked as expected. So it does imply there is a z/VM maintenance
dependency
>
On Wed, Apr 13, 2005 at 11:51:46AM -0400, Dennis Musselwhite wrote:
> VM63261 is a z/VM 4.3.0 APAR and the most recent service affecting Guest LAN
> on z/VM 4.3.0 would be VM63655 (PTF UM31332) and all prereqs. If that does
> not fix the problem we will need more diagnostic informatio
er
> Unicast IP Addresses:
> 172.18.8.31 Mask: 255.255.255.0
(3) Your IP Address has been registered on the Guest LAN.
Check the target user to see if it was successfully
registered with the address you intended.
> FE80::200:0:500:4/64
>
G'day all,
I'm stumped. I just applied SP1 to a working SLES9 system, and after the
IPL my Guest LAN connection now appears to be non-functional. I've checked
all the obvious things but so far I'm none the wiser. Connectivity to
another system on the same Guest LAN is fin
On Tue, Nov 23, 2004 at 01:58:17PM -0500, Martha McConaghy wrote:
> I still don't know why it stopped working, but it is nice to have the
> network connection again. While you are helping out a Linux neophyte,
> can you tell me where Suse puts boot scripts? I'm going to have to
> automate this s
t: Re: Problems with SLES 9 and guest lan
Thanks for the help everyone, especially Neale! A variation of his
script did the trick.
modprobe qdio
modprobe ccwgroup
modprobe qeth
echo 0.0.4000,0.0.4001,0.0.4002 >/sys/bus/ccwgroup/drivers/qeth/group
echo VOSASW > /sys/bus/ccwgroup/drivers/qeth/0
Thanks for the help everyone, especially Neale! A variation of his
script did the trick.
modprobe qdio
modprobe ccwgroup
modprobe qeth
echo 0.0.4000,0.0.4001,0.0.4002 >/sys/bus/ccwgroup/drivers/qeth/group
echo VOSASW > /sys/bus/ccwgroup/drivers/qeth/0.0.4000/portname
echo 1 > /sys/bus/ccwgroup/dr
Because in my situation qdio was being loaded by the scsi driver load.
The qeth was occuring before scsi.
-Original Message-
The qdio.ko module needs to be loaded before qeth.ko one. Don't know
why
Neale's script didn't do that first. (This is why I always try to use
modprobe instead of
[mailto:[EMAIL PROTECTED] On Behalf Of Martha
McConaghy
Sent: Tuesday, November 23, 2004 12:02 PM
To: [EMAIL PROTECTED]
Subject: Re: Problems with SLES 9 and guest lan
Neale,
Thanks very much for the script. I've tried the commands out and got some
interesting results. When I ran the sec
ond to
Linux on 390 Port
To
[EMAIL PROTECTED]
cc
Subject
Re: Problems with SLES 9 and guest lan
Neale,
Thanks very much for the script. I've tried the commands out and got some
interesting results. When I ran the second line, I received the
following:
insmod /lib/modules/`uname
>insmod /lib/modules/`uname -r`/kernel/drivers/s390/net/qeth.ko
>qeth: Unknown symbol qdio_synchronize
>qeth: Unknown symbol do_QDIO
>qeth: Unknown symbol qdio_initialize
>qeth: Unknown symbol qdio_cleanup
>qeth: Unknown symbol qdio_activate
>Nov 23 08:57:19 lsuse964 kernel: qeth: Unknown symbol qd
try and load the qdio prior to the others and see what happens...
-Original Message-
From: Linux on 390 Port [mailto:[EMAIL PROTECTED] Behalf Of
Martha McConaghy
Sent: Tuesday, November 23, 2004 12:02 PM
To: [EMAIL PROTECTED]
Subject: Re: [LINUX-390] Problems with SLES 9 and guest lan
Neale,
Thanks very much for the script. I've tried the commands out and got some
interesting results. When I ran the second line, I received the following:
insmod /lib/modules/`uname -r`/kernel/drivers/s390/net/qeth.ko
http://www.marist.edu/htbin/wlvindex?LINUX-390
I ran into this problem when I installed the SLES9 beta. I didn't have
the problem when I upgraded using the GA level. It appears to me that
qdio is not being started early enough (i.e. before qeth is attempted to
be started). I wrote the following script that I used to bring up the
eth connection:
On Nov 23, 2004, at 8:45 AM, Martha McConaghy wrote:
Running zipl did seem to change things a bit. However, the problem
still occurssigh Sounds like I'm the first or only one to hit
this.
If it's any consolation, the 2.6 udev stuff is pretty confusing to me
too. The Device Drivers book m
Running zipl did seem to change things a bit. However, the problem
still occurssigh Sounds like I'm the first or only one to hit this.
Martha
--
For LINUX-390 subscribe / signoff / archive access instructions,
send emai
> Yes. uname -r returns 2.6.5-7.111-s390x . There is a directory
> in /lib/modules that corresponds to this name.
Are you in runlevel 3 (or something other than 1)? runlevel will tell.
> Being new to Linux, I've been doing most of my work through Yast,
> including downloading and applying patc
On Mon, 22 Nov 2004 13:46:56 -0500 Daniel Jarboe said:
>> I have a 64-bit SLES 9 test system that I've been playing with. I
>> recently applied some patches that Suse had recommended applying.
>> After I recycled the system, it will no longer talk to the guest lan.
&g
> I have a 64-bit SLES 9 test system that I've been playing with. I
> recently applied some patches that Suse had recommended applying.
> After I recycled the system, it will no longer talk to the guest lan.
> It worked prior to the patches and no changes have been been made on
&
y.
/Thomas Kern
/301-903-2211
> -Original Message-
> From: Alan Altmark [mailto:[EMAIL PROTECTED]
> Sent: Friday, April 02, 2004 13:58
> To: [EMAIL PROTECTED]
> Subject: Re: Adding QDIO guest lan to server
>
> Everyone has access to the source code. One of my favorite U
wall server will then connect to a
> different guest lan, VMLAN01 for our inside work and VMLAN02 for the
outside
> work. All of the NICs attached to the VMLAN00 lan are address E00-E02
with
> Portname VMLAN00, except for the OS/390 NIC at address E000-E002,
portname
> IUTIQDE0.
>
> I
connect to a
different guest lan, VMLAN01 for our inside work and VMLAN02 for the outside
work. All of the NICs attached to the VMLAN00 lan are address E00-E02 with
Portname VMLAN00, except for the OS/390 NIC at address E000-E002, portname
IUTIQDE0.
I have an outside webserver connected to VMLAN02
TED]
> Subject: Re: Adding QDIO guest lan to server
>
> Problem: By using autoconfiguration (the "-1") you are going to end up
> with lcs0 and qeth0. Assuming the LCS device is an ethernet,
> Linux will
> try to create *interface* names of eth0 for both devices.
> One w
On Friday, 04/02/2004 at 12:15 EST, "Kern, Thomas"
<[EMAIL PROTECTED]> wrote:
> Can someone in IBM or someone with the source code for QETH, please tell
me
> what IDX TERMINATE and cause code 0x22 mean?
Everyone has access to the source code. One of my favorite URLs is
http://lxr.linux.no/source/
On Friday, 04/02/2004 at 12:27 EST, "Post, Mark K" <[EMAIL PROTECTED]>
wrote:
> I believe that the order of the cards in /etc/chandev.conf is
significant.
> I've always seen it coded this way:
> # cat /etc/chandev.conf
> qeth0,0x0f10,0x0f11,0x0f12
> add_parms,0x010,0x0f10,0x0f12,portname:LINUXSRV
>
Could it be a syntax problem
you have:
lcs-1,0x3ad0,0x3ad1,0,3
qeth-1,0x0e04,0xe05,0x0e06,0,0
lcs1 and qeth1 without the dash.
=
Jim Sibley
RHCT, Implementor of Linux on zSeries
"Computer are useless.They can only give answers." Pablo Picasso
__
Do you Yahoo
On Friday, 04/02/2004 at 11:55 CST, Rich Smrcina <[EMAIL PROTECTED]>
wrote:
> For what it's worth here's the pertinent entry in my chandev.conf:
>
>
noauto;qeth0,0x0800,0x0801,0x0802;add_parms,0x10,0x0800,0x0802,portname:GL1
>
> If this is the first machine to use t
This virtual machine is LNXRHFW. It is authorized to connect its virtual NIC
E04 to guest lan VMLAN01. During these tests it is the ONLY server
connecting to VMLAN01. The virtual NIC is currently defined and coupled in
the PROFILE EXEC, eventually to be done in the user directory. The eventual
use
For what it's worth here's the pertinent entry in my chandev.conf:
noauto;qeth0,0x0800,0x0801,0x0802;add_parms,0x10,0x0800,0x0802,portname:GL1
If this is the first machine to use the Guest Lan it will be able to set
the name, so what you use really doesn't matter. All of the othe
--Original Message-
> From: Post, Mark K [mailto:[EMAIL PROTECTED]
> Sent: Friday, April 02, 2004 12:28
> To: [EMAIL PROTECTED]
> Subject: Re: Adding QDIO guest lan to server
>
> I believe that the order of the cards in /etc/chandev.conf is
> significant.
> I'
ce.
Mark Post
-Original Message-
From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of Rich
Smrcina
Sent: Friday, April 02, 2004 12:20 PM
To: [EMAIL PROTECTED]
Subject: Re: Adding QDIO guest lan to server
It indicates that the portname is wrong. Verify the port name with Q LAN
D
It indicates that the portname is wrong. Verify the port name with Q
LAN DETAILS.
On Fri, 2004-04-02 at 11:15, Kern, Thomas wrote:
> Can someone in IBM or someone with the source code for QETH, please tell me
> what IDX TERMINATE and cause code 0x22 mean?
>
> This is a RHEL system build during th
Can someone in IBM or someone with the source code for QETH, please tell me
what IDX TERMINATE and cause code 0x22 mean?
This is a RHEL system build during the Taroon beta.
/Thomas Kern
/301-903-2211
ifconfig eth1 10.0.1.1
qdio: loading QDIO base support version 2 ($Revision: 1.145 $/$Revision:
xe04,0xe06,portname:VMLAN02
qeth2,0xe04,0xe05,0xe06,0,0
/Thomas Kern
/301-903-2211
> -Original Message-
> From: Post, Mark K [mailto:[EMAIL PROTECTED]
> Sent: Thursday, April 01, 2004 12:00
> To: [EMAIL PROTECTED]
> Subject: Re: Adding QDIO guest lan to server
&
,
Thomas
Sent: Thursday, April 01, 2004 11:47 AM
To: [EMAIL PROTECTED]
Subject: Re: Adding QDIO guest lan to server
After changing 'CHANDEV=noauto,' to 'CHANDEV=noauto;' this is what I get.
cat /etc/chandev.conf
chandev=noauto;lcs0,0x39eo,0x39e1,0,0,1,1
add_parms,0x10,0xe00,0x
CTED]
Sent: Thursday, April 01, 2004 11:47 AM
To: [EMAIL PROTECTED]
Subject: Re: Adding QDIO guest lan to server
After changing 'CHANDEV=noauto,' to 'CHANDEV=noauto;' this is what I get.
cat /etc/chandev.conf
chandev=noauto;lcs0,0x39eo,0x39e1,0,0,1,1
add_parms,0x1
n:
1.43 $)
/Thomas Kern
/301-903-2211
> -Original Message-
> From: Geiger, Mike [mailto:[EMAIL PROTECTED]
> Sent: Thursday, April 01, 2004 11:30
> To: [EMAIL PROTECTED]
> Subject: Re: Adding QDIO guest lan to server
>
>
> Thomas,
>
> Been there, done that... jus
lto:[EMAIL PROTECTED]
Sent: Thursday, April 01, 2004 11:01 AM
To: [EMAIL PROTECTED]
Subject: Re: Adding QDIO guest lan to server
I removed JUST the "chandev=" string preserving the rest of the line. The
LCS code attempted to initialize but failed saying it could not find any LCS
capable
Thursday, April 01, 2004 10:52
> To: [EMAIL PROTECTED]
> Subject: Re: Adding QDIO guest lan to server
>
>
> Did you remove the complete chandev= statement, or just remove the
> "chandev=" part of it? You need the rest of the stat
homas
Sent: Thursday, April 01, 2004 9:01 AM
To: [EMAIL PROTECTED]
Subject: Re: Adding QDIO guest lan to server
The Q NIC shows E04/E05/E06 and the original CHANDEV.CONF reads E03/E04/E05
because I changed from 3/4/5 to 4/5/6 to see if that would fix it and then I
did the Q NIC to respond to Mark.
L
On Thu, 1 Apr 2004 09:01:06 -0500 Kern, Thomas said:
>
>Last night I took out the chandev= string and rebooted. The LCS driver
>failed to come up but the QETH driver worked fine. There does seem to be
>some incompatibility between LCS and QETH. I doubt IBM ever tried both in
>the same linux server.
no manual entry for chandev. I am
attaching the output of 'cat /proc/chandev' to this email.
/Thomas Kern
/301-903-2211
> -Original Message-
> From: Dennis Musselwhite [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, March 31, 2004 20:55
> To: [EMAIL PROTECTED]
> Su
continue to define your NIC starting on an
even device number and adjust your /etc/chandev.conf to match. The OSA
Express now allows odd/even pairs for the read and write control devices,
but Guest LAN does not allow that yet.
You have portname defined for both interfaces in /etc/chandev.conf, and the
lto:[EMAIL PROTECTED] On Behalf Of Scorch
Burnet
Sent: Wednesday, March 31, 2004 5:52 PM
To: [EMAIL PROTECTED]
Subject: Re: Adding QDIO guest lan to server
I believe that there can be only one portname per osa card and taht name is
case sensitive... I defined the portname when i set up vm. since i
1 - 100 of 205 matches
Mail list logo
