Alan Altmark wrote on 10/27/2006 06:25:07 PM: > On Friday, 10/27/2006 at 05:47 EST, Dennis Schaffer > <[EMAIL PROTECTED]> wrote: > > There was some confusion about whether any z/OS systems were sharing the > > OSA port with VM during the test; I heard two different answers to the > > question. > > > > So, it seems plausible that SETing the VSWITCH definition to specify > > PRIROUTER might have corrected this problem. Its too bad VSWITCH > doesn't > > support a SECROUTER option similar to TCPIP itself. > > Are you saying that you can reach the guests behind your virtual router > via another path? (It seems strange to me that you would want data to > normally route via some other path rather than directly via the VSWITCH.
Alan, I didn't mean to imply that I could reach the zLinux guests from the general network via some other path rather than the VSWITCH. I was able to connect to the z/VM system itself using TCPIP TN3270 and, from there, logon to the virtual console of each of the zLinux guests. From there I could ping all of the other zLinux systems as well as the Guest LAN gateway, VM's VIPA and VSWITCH addresses. I could not connnect to any of the zLinux systems connected to the Guest LAN from the general network while VM was configured using VSWITCH. Or, as I've now discovered to be a more accurate statement, while the VSWITCH was configured as NONROUTER. > If the only path to those guests is via your virtual router, then you MUST > be PRIROUTER. The whole concept of PRIROUTER is that the owning OSA is > connected to a routing host. You can have your cake or eat it, not both. > :-) I keep saying "Do not share OSAs being used by VSWITCHes." (It's not > that you can't, it's that you *shouldn't*.) In my production environment, this z/VM system shares its OSA adapters with three other z/OS systems. One of these z/OS systems was recently reconfigured as the PRIROUTER TCPIP stack because of (1 the need to establish a hipersockets connection between this and another z/OS system and (2 the importance of its workload to our organization causing it to be the first mainframe system normally IPLd in our shop. It would be ideally wonderful to purchase two dedicated $10K OSA adapters for our z/VM system (as well as the network infrastructure required to support those adapters). However, our combined z/OS and z/VM workloads utilize a small fraction of our existing OSA cards so it doesn't make much sense to spend those dollars for that purpose. In our environment, we would much rather spend those dollars (or a significant fraction thereof) to purchase 2Gb (assuming it were possible to purchase memory in 2Gb increments) of central storage because we are utilizing a very high percentage of our storage. Our Disaster Recovery vendor has apparently chosen to spread our combined workloads across multiple OSA ports (or adapters, I'm not sure) even though we're only contracted for one port and thats what affected us during this test. Its apparently easy (via SET VSWITCH command) to change a VSWITCH between PRIROUTER and NONROUTER but we're required to be cognizant of that configuration in order to know which option to choose. If VSWITCH also supported the SECROUTER option (similar to the TCPIP stack itself), we would not have to be aware of the specific OSA adapter configuration; VSWITCH would dynamically configure itself as PRIROUTER or NONROUTER, depending on the existing configuration. But, I understand it doesn't and that's partly why you recommend dedicated OSAs. > That said, if you don't have VM TCPIP on the VSWITCH, and if you aren't > using VLANs, you can change it to TYPE ETHERNET (layer 2). PRIROUTER is > not required in that case since packets are routed by MAC address, not IP > address. These requirements don't apply to our shop. Thanks, Dennis
