If I understood this thread correctly, then I think the issue is that traffic for the guests of the first level VM (whether second or third lev el) are not getting their intended traffic. This sounds like a normal situati on with the firltering done on the control unit that sees to it that the VM system does not get awakened for things not intended for it. While someo ne suggested that you just give each VM guest its own OSA control unit to gi ve it an exposure on the LAN, I believe there is a simpler way. The followi ng are from some charts of an old presentation that I gave at SHARE a few ti mes when the support was new in FLEX-ES a few years ago. I think it may be applicable here. (Hopefully formatting that I do not want will not mess it up in the post.)
New options for TCP/IP * Multiple ipaddress= options on network device *Especially usefully if using z/VM TCP/IP proxyarp for z/VM guests ... vmosa: cu osa interface local(1) options ipaddress=192.168.1.139,ipaddress=192.168.1.140 ... * The .139 could be VM and the .140 could be a guest of the same VM system receiving its traffic through the VM TCP/IP stack * Up to 14 addresses may be specified z/VM guest LANs are usually subnetted differently than z/VM TCP/IP stack * Allowing an entire subnet through filter is useful. Specify number of mask bits after / * Example: options ipaddress=192.168.1.139,ipaddress=192.168.2.0/24 192.168.2.0 thru 192.168.2.255 are allowed through for guest LAN on 192.168.2 network You should check the FLEX-ES documentation for further explanation of the se control unit options. -- Gary Eheman Fundamental Software, Inc. http://www.funsoft.com
