Re: Vswitch problem on z/VM 5.2.0?
You should be able to just leave the VLAN parameter off and let it default to VLAN UNAWARE. Rick Barlow Systems Engineering Consultant Nationwide Services Co., Enterprise Business Intelligence Services Mainframe, z/VM and zSeries Linux Support One Nationwide Plaza 3-25-02 Columbus OH 43215-2220 U.S.A Voice: (614) 249-5213Fax: (614) 677-7681 mailto:[EMAIL PROTECTED] VM/ESA and z/VM Discussions VMESA-L@LISTSERV.UARK.EDU wrote on 03/07/2006 02:40:29 PM: VMESA-L@LISTSERV.UARK.EDU On Mon, 6 Mar 2006 18:40:11 -0500, Alan Altmark [EMAIL PROTECTED] wrote: From the book, The defvid defines the default VLAN ID to be associated with untagged frames received and transmitted by the Virtual Switch. This is also known as the native VLAN id in the switch. They must match. I checked with the Network group and according to them they do not have any native VLAN id set up - they do not want any untagged traffic in the network. What would I use in my DEFINE SWITCH for the defvid in this case? Is an unused VLAN number acceptable? Brian Nielsen
Re: Vswitch problem on z/VM 5.2.0?
I think the problem is your VLAN ID on the DEFINE VSWITCH. That value needs to match the management VLAN ID for the switch to which your OSA is connected. The normal default is 1. Your installation may have changed the value. You will need to talk to the group that configures your switch hardware. Rick Barlow Systems Engineering Consultant Nationwide Services Co., Enterprise Business Intelligence Services Mainframe, z/VM and zSeries Linux Support One Nationwide Plaza 3-25-02 Columbus OH 43215-2220 U.S.A Voice: (614) 249-5213Fax: (614) 677-7681 mailto:[EMAIL PROTECTED] VM/ESA and z/VM Discussions VMESA-L@LISTSERV.UARK.EDU wrote on 03/06/2006 03:17:23 PM: VMESA-L@LISTSERV.UARK.EDU This weekend I upgraded from z/VM 4.4.0 to 5.2.0 and ran into an unexpected problem with connectivity through vswitches to the external network. I'm trying to figure out if the problem is in my vswitch definitions or if it's a reportable issue. At the moment it appears that private IP address ranges (eg 192.168.xxx.xxx, 10.xxx.xxx.xxx, 172.16.64.xxx) which worked fine through a vswitch in 4.4.0 do not work at all through a vswitch on 5.2.0. Private IP addresses in the same subnet, on the same VLAN, on the same vswitch couldn't ping each other or their external gateway. The public IP addresses on the same vswitch had no trouble pinging their external gateway. Private IP addresses with direct OSA conections had no problems either. I was able to confirm it was a vswitch related problem through testing with my z/VM TCPIP stack. Normally it has a dedicated OSA connection and a private IP address of 172.16.64.3 on VLAN 7. On zVM 5.2 I was able to PING its external gateway at 172.16.64.1. When I changed the TCPIP stacks network connection from a dedicated OSA to a virtual NIC on the vswitch the ping failed. My vswitch was defined in z/VM 4.4.0 with: DEFINE VSWITCH SWITCH02 RDEV 0500 F804 PORTNAME PT0500 PTF804 and in 5.2.0 with: DEFINE VSWITCH SWITCH02 RDEV 0500 F804 VLAN 7 PORTNAME PT0500 PTF804 For testing the TCPIP NIC on the vswitch it was authorized with: SET VSWITCH SWITCH02 GRANT TCPIPVLAN 7 In both cases, PROFILE TCPIP includes: LINK ETH0 QDIOETHERNET [EMAIL PROTECTED] VLAN 7 Changing TCPIP's GRANT to include PORTTYPE TRUNK, and verifying the change with Q VSWITCH ALL DETAILS, had no effect. On the exact same switch, SWITCH02, other Linux guests on VLAN 2 with public IP addresses (eg 164.165.57.xxx) had no trouble communicating with the network outside the z/890. They are authorized to the vswitch with: SET VSWITCH SWITCH02 GRANT userid VLAN 2 The problem also manifested itself on the other vswitch carrying traffic on private IP addresses for other VLANs (3 and 4). Is there something I've overlooked in the changes to vswitches from 4.4.0 to 5.2.0? Or is this a reportable problem? Brian Nielsen P.S. The problem has been temporariliy circumvented by connecting the userids with priviate IP address on VLAN 7 to a guest LAN and using the zVM TCPIP stack to route their traffic to the OSA. (Yuck, but it works.)
Re: I have to use the 'O' word.
You can put an OS VTOC on the voluems using ICKDSF. The control statements would look something like this: INIT UNIT(dev) VOLID(volser) - VTOC(001,00,150) INDEX(000,01,14) - MAP NOVERIFY NOCHECK NOVALIDATE Rick Barlow Systems Engineering Consultant Nationwide Services Co., Enterprise Business Intelligence Services Mainframe, z/VM and zSeries Linux Support One Nationwide Plaza 3-25-02 Columbus OH 43215-2220 U.S.A Voice: (614) 249-5213Fax: (614) 677-7681 mailto:[EMAIL PROTECTED] VM/ESA and z/VM Discussions VMESA-L@LISTSERV.UARK.EDU wrote on 02/08/2006 08:21:34 AM: VMESA-L@LISTSERV.UARK.EDU Hello. We are a VM shop only, therefore our DASD is formatted for VM and have a VM VTOC. Is it possible to put an osvtoc (the 'O' word g) on these volumes without totally reformatting the drive, etc? Thanks, Steve G.
Are you using Virtual Linux and SCSI or FCP DASD?
I am cross-posting this question to both the VMESA-L and LINUX-390 lists. I am looking for anyone who might be willing to share experience using SCSI/FCP DASD on zSeries with Linux. We are currently doing all of our virtual Linux with CKD DASD. Many potential applications really need amounts of disk space that are only practical with open systems storage. If anyone is willing to share information about a configuration they have working I would be very interested. I am looking for combinations of information like: z990; z/VM v.r; SuSE Linux; IBM SHARK/DS8000 or EMX x or STK x; dedicated SCSI to guest or z/VM-controlled with mini-disks. Any experience with DASD other than IBM SHARK would be particularly interesting. Rick Barlow Systems Engineering Consultant Nationwide Services Co., Enterprise Business Intelligence Services Mainframe, z/VM and zSeries Linux Support One Nationwide Plaza 3-25-02 Columbus OH 43215-2220 U.S.A Voice: (614) 249-5213Fax: (614) 677-7681 mailto:[EMAIL PROTECTED]
Re: OSA-ICC
We have 2 new z990 systems and both have the OSA-ICC feature. I have to disagree with Shimon in that they have worked very well for us. We have basically supported these 2 new machines remotely and the ICCs have worked great. We have configured several emulators to work with them. We have used Vista32, Attachmate and X3270 under Cygwin. All have worked well. Attachmate is the most difficult to configure and has caused us the most problems. This may be due to the many varied releases that can be found on varies PCs. We have seen the problem where all of the ports go dead for some unknown reason and we have not been able to resolve this issue yet. We have been able to use CP DISABLE and ENABLE to get the devices working again. We do this be accessing the LPARs via TELNET and the VM TCP/IP stack. This is only a viable solution if you have some other way to access VM CP so you can issue the commands. Rick Barlow Systems Engineering Consultant Nationwide Services Co., Technology Engineering and Operations Support, Mainframe, VM Support One Nationwide Plaza 3-25-02 Columbus OH 43215-2220 U.S.A Voice: (614) 249-5213Fax: (614) 677-7681 mailto:[EMAIL PROTECTED]
