Thanks Kris!
I'm 90% confident the problem is NOT in the Directory. This guest
autologged and acquire the nic def fine while it was being tested. It was
started and stopped multiple times w/o incident. The problem did not occur
until the Linux admin changed the IP addresses for this guest (guest2) to
those of the old guest (guest1). After the IP change (NO directory changes
have been made since the guest was first defined) guest2 would not
'automatically' acquire 304.
I tried to explain all of this in the original post, I know this is a
convoluted situation
I have found the following in the guest startup log:
<6>qeth: loading qeth S/390 OSA-Express driver
<4>qeth: Device 0.0.0300/0.0.0301/0.0.0302 is a Guest LAN QDIO card (level:
V52I)
<4>with link type GuestLAN QDIO (portname: )
<6>qeth: Hardware IP fragmentation not supported on eth0
<6>qeth: VLAN enabled
<6>qeth: Multicast enabled
<6>qeth: IPV6 enabled
<6>qeth: Broadcast enabled
<4>qeth: Using SW checksumming on eth0.
<4>qeth: Outbound TSO not supported on eth0
RIGHT HERE>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
<4>qeth: Device 0.0.9006/0.0.9007/0.0.9008 is a HiperSockets card (level: …
()
In our other SLES 10 guests at the RIGHT HERE, the same sequence of
messages are displayed for 304, as you can see that doesn't happen here.
Im not linux enough to have a guess what this might indicate. The Linux
group is looking at it from their end as well.
Steve Mitchell
Sr Systems Software Specialist
Blue Cross Blue Shield of Kansas
(785) 291-8885
'There are no degrees of Honesty-you're either Honest or you're not!
Kris Buelens
<[EMAIL PROTECTED]
il.com> To
Sent by: The IBM [email protected]
z/VM Operating cc
System
<[EMAIL PROTECTED] Topic
ARK.EDU>
Subject
Re: NIC not acquired at startup
10/09/2008 06:11
PM
Please respond to
The IBM z/VM
Operating System
<[EMAIL PROTECTED]
ARK.EDU>
With an XAUTOLOG followed by a SET SECUSER, you can still mis lots of
error messages: surely all those caused by LINKs in the directory that
fail, and possibly the first messages resulting from actions in the
PROFILE EXEC.
I guess that a failing NICDEF (included in the CP directory) will just
be like LINK: unnoticed when using XAUTOLOG#SET SECUSER.
To see all problems resulting from directory statements, only 2 solutions
- logon directly to the user
- have you as secondary user on the user's CONSOLE statement and use
XAUTOLOG
(or have OPERATOR as secuser and look in OPERATOR's console log)
Not even a COMMAND SPOOL CONS START in the directory will catch
failing LINKs: the classic, old, directory statements are executed
before the COMMAND statements.
Replacing
USER
NICDEF ...
LINK ...
By
USER ...
COMMAND SPOOL CONS START
COMMAND NICDEF ...
COMMAND LINK ...
will assure the errors are in de spooled console file
2008/10/9 Scott Rohling <[EMAIL PROTECTED]>
>
> How about the VM console log? I would want to see what messages are
occurring on the VM console when the guest starts up...
>
> Or to watch it: XAUTOLOG LINUX1 SYNCH#SET SECUSER LINUX1 *
>
> Or login directly to watch
>
> Scott Rohling
--
Kris Buelens,
IBM Belgium, VM customer support
CONFIDENTIALITY NOTICE: This email message and any attachments are for the sole
use of the intended recipient(s) and may contain proprietary, confidential,
trade secret or privileged information. Any unauthorized review use,
disclosure or distribution is prohibited and may be a violation of law. If you
are not the intended recipient or a person responsible for delivering this
message to an intended recipient, please contact the sender by reply email and
destroy all copies of the original message.
