On Fri, Nov 08, 2002 at 10:57:41AM -0500, Dave Myers wrote:
> So according to the statements below...I CAN use SUSE SLES7
> to play the guest lan game, using QDIO instead of virtual hipersockets?
> Am I correct in this assumption?
> Any testimony from someone who has setup guest lans with SUSE SLES7?
> Tia
> Dave Myers
Yeah, as long as you're running one of the more recent patches that
fixes virtual qeth support, it works fine.
On a virtual LAN, the only difference is whether you specify it as type
QDIO or leave it unset (in the VM LAN definition statment).
Then if it's a qdio LAN, you define your virtual NIC to the guest as
TYPE QDIO (which really means OSA, since both HiperSockets and OSA are
QDIO devices).
Virtual OSAs support broadcast (under z/VM 4.3). HiperSockets don't.
That's pretty much the difference between them. They use the same
driver, but OSA is aliased to interface ethX and HiperSockets to hsiX.
Here's something from an SLES-based guest...
r2:~ # ifconfig
eth2 Link encap:Ethernet HWaddr 00:00:00:00:00:00
inet addr:192.168.130.67 Mask:255.255.255.192
inet6 addr: fe80::200:ff:fe00:0/10 Scope:Link
UP RUNNING NOARP MULTICAST MTU:1492 Metric:1
RX packets:473155 errors:0 dropped:0 overruns:0 frame:0
TX packets:553105 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:45294696 (43.1 Mb) TX bytes:161088571 (153.6 Mb)
Interrupt:17
eth2:0 Link encap:Ethernet HWaddr 00:00:00:00:00:00
inet addr:192.168.130.68 Mask:255.255.255.192
UP RUNNING NOARP MULTICAST MTU:1492 Metric:1
Interrupt:17
hsi0 Link encap:Ethernet HWaddr 00:00:00:00:00:00
inet addr:192.168.129.4 Mask:255.255.255.0
inet6 addr: fe80::200:ff:fe00:0/10 Scope:Link
UP RUNNING NOARP MULTICAST MTU:8192 Metric:1
RX packets:2517010 errors:0 dropped:0 overruns:0 frame:0
TX packets:1719082 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:1009596522 (962.8 Mb) TX bytes:276571455 (263.7 Mb)
Interrupt:11
hsi0:0 Link encap:Ethernet HWaddr 00:00:00:00:00:00
inet addr:192.168.129.5 Mask:255.255.255.0
UP RUNNING NOARP MULTICAST MTU:8192 Metric:1
Interrupt:11
hsi1 Link encap:Ethernet HWaddr 00:00:00:00:00:00
inet addr:192.168.130.2 Mask:255.255.255.192
inet6 addr: fe80::200:ff:fe00:0/10 Scope:Link
UP RUNNING NOARP MULTICAST MTU:8192 Metric:1
RX packets:1660330 errors:0 dropped:0 overruns:0 frame:0
TX packets:2378314 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:211072990 (201.2 Mb) TX bytes:977121122 (931.8 Mb)
Interrupt:14
hsi1:0 Link encap:Ethernet HWaddr 00:00:00:00:00:00
inet addr:192.168.130.4 Mask:255.255.255.192
UP RUNNING NOARP MULTICAST MTU:8192 Metric:1
Interrupt:14
lo Link 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:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
Notice that I have one "eth" device and two "hsi" devices. These are
all virtual; this router lives on two HiperSockets and one OSA segment.
Also note the dummy addresses (XXXN:0): this is VRT in action; r1
contains the other side of the pair, but r2 is currently holding the
virtual addresses. Here's the routing table...
r2:~ # route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
192.168.131.0 192.168.130.10 255.255.255.192 UG 0 0 0 hsi1
192.168.131.64 192.168.130.10 255.255.255.192 UG 0 0 0 hsi1
192.168.130.0 0.0.0.0 255.255.255.192 U 0 0 0 hsi1
192.168.130.64 0.0.0.0 255.255.255.192 U 0 0 0 eth2
192.168.129.0 0.0.0.0 255.255.255.0 U 0 0 0 hsi0
0.0.0.0 192.168.129.1 0.0.0.0 UG 0 0 0 hsi0
Adam
