Now I am confused. Please correct me when I am wrong.
When I create guestlan of QDIO type, VM can handle it
for its guests. It doesn't need real hipersocket.
Guests use virtual NIC so it can work even when there
are no real OSA adapters. Of course there is at least
one for VM itself, but guestlan does not use it.
My qdio.o is 1.145, qeth.o is 1.337.4.5. Those are the
latest versions I know.
During guest IPL I get
qdio: loading QDIO base support version 2 ($Revision:
1.145 $/$Revision: 1.66.4.1 $)
qdio: Was not able to determine general
characteristics of all Hydras aboard.
qeth: loading qeth S/390 OSA-Express driver
($Revision: 1.337.4.5 $/$Revision: 1.113.4.1
$/$Revision: 1.42.4.1 $:IPv6:VLAN)
qeth: allocated 0 spare buffers
qeth: Trying to use card with devnos 0x700/0x701/0x702
qeth: Device 0x700/0x701/0x702 is an OSD Express card
(level: 2938)
with link type Gigabit Eth (no portname needed by
interface)
qeth: VLAN not supported on eth0
qeth: IPv6 not supported on eth0
qeth: Could not set up broadcast filtering on eth0:
0x2, continuing
eth0: no IPv6 routers present
guestlan with static addresses work, only DHCP fails
Am I right if I say it has nothing to do with real hw
errors ? That it is sw error either in VM or in
qdio/qeth drivers ?
I don't have VM background and I didn't get answer on
VM list regarding my receive/apply, maybe someone here
would answer it ( although these two mailing lists
have huge intersection :)) Can anybody explain this ?
PTF: UM30652 APAR: VM63172
------------------------------
Receive status: RECEIVED.10/24/03.06:20:56.MAINT
Apply status: APPLIED.07/03/03.15:37:38.MAINT
Thank you
Marian
--- Dennis Musselwhite <[EMAIL PROTECTED]> wrote:
> Hi,
>
> APAR VM63172 (PTF UM30652) provided or improved
> support for some functions
> that the Linux device drivers needed to better
> support applications like
> DHCP. Our focus at that time was the QDIO model
> because it included the
> necessary broadcast support. APAR VM63172 made it
> possible for the qeth
> driver to obtain the MAC address that we generated
> for the virtual NIC.
>
> I can imagine a couple of reasons why the
> HiperSockets connections might
> still show MAC of zeroes:
> (1) Older qeth drivers did not send the request for
> MAC address to our
> simulated adapters because of IPv6 capabilities.
> Apparently the hardware
> added this support along with IPv6 so our lack of
> IPv6 capability in z/VM
> 4.3.0 implied that we also could not handle the
> request for MAC address.
> The qeth developers released an update to fix this
> before VM63172 was
> released, so make sure you have recent qdio/qeth
> modules.
> (2) The "real" HiperSockets facility DOES NOT
> provide a MAC address at all.
> It is entirely possible that qeth does not bother
> sending the request to a
> HiperSockets adapter ("real" or simulated).
>
> If you define a TYPE QDIO adapter on the same guest
> and bring up the
> interface, the ifconfig command should report the
> same MAC address that you
> see with CP QUERY NIC details. That would indicate
> that your drivers are
> new enough to handle the request.
>
> Regards,
> Dennis
>
----------------------------------------------------------------
> Dennis Musselwhite ([EMAIL PROTECTED])
> z/VM Development -- CP Network Simulation -- IBM
> Endicott NY
=====
===================
Marian Gasparovic
===================
"The mere thought hadn't even begun to speculate about the merest possibility of
crossing my mind."
__________________________________
Do you Yahoo!?
Exclusive Video Premiere - Britney Spears
http://launch.yahoo.com/promos/britneyspears/
