Re: SLES 11 strange behavior network
Rogerio,
z/VM assigns MAC-addresses for virtual NICs. I assume the MAC-address
assigned to your SLES11 virtual NIC has changed after LOGOUT and this
change is not propagated to your network. If this is correct, I see 2
options to work around this problem:
1. Overwrite the z/VM-assigned MAC-address with a user-defined
MAC-address using an LLADDR-definition line
in /etc/sysconfig/network/ifcfg-ethx. Thus the MAC-address does not
change after LOGOUT.
2. Run an arping-command after ifup:
/sbin/arping -q -A -c 1 -I ${REALDEVICE} ${IPADDR}
to update your neighbours.
Regards,
Ursula Braun, IBM Germany
On Tue, 2011-02-01 at 15:49 -0200, Rogério Soares wrote:
Guys, i get another ghost on my enviroment...
i set up my vswitch to use port group, and give grant permission to guest
sles 11 Sp1..
all works okay, but if i give LOGOUT on machine, network not comes back,
until i give some network request FROM this machine.. this request can be a
ping for example...
instantly i give a ping, the nework wake up... anybody already see this
behavior ? any clue?
this behavior not happens if i give a simple reboot command :-/
here is my definitions of vswitch and port group:
00242 VMLAN MACPREF 026101
00243 MOD PORT GROUP GRPSRV01 JOIN 1D00.P0 1E00.P0
00244 DEFINE VSWITCH VSWSVC01 ETHERNET RDEV 0800.P0 GROUP GRPSRV01
00245
00246 MODIFY VSWITCH VSWSVC01 GRANT DB2P101
on linux, we are currentily using vlan
--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/
AUTO: Libby Coleman is out of the country on Education with limited email access, back on Monday 7th February. (returning 07/02/2011)
I am out of the office until 07/02/2011. In an emergency please contact my manager Ian Lyon (ian_l...@uk.ibm.com) Tel: 07967-275335 (Mobex 37275335) Note: This is an automated response to your message LINUX-390 Digest - 31 Jan 2011 to 1 Feb 2011 (#2011-26) sent on 2/2/11 5:00:31. This is the only notification you will receive while this person is away. -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
Re: multipath doesn't work
Date: nbsp; nbsp;Thu, 27 Jan 2011 09:13:16 -0400 From: nbsp; nbsp;Victor Echavarry Diaz vechava...@evertecinc.com Subject: multipath doesn't work We have a SLES 10 SP2 working server connect to a IBM XIV with 4 LUNS=2E Fo= r some reason the DBA wants to reinstall the server again=2E After we clone= nbsp;it we connect the XIV with round robin multipath=2E When we reboot it we g= et the following messages:=0A=0AKernel: device-mapper: table: 253:14: multi= path: error getting device=0AKernel: device-mapper: ioctl: error adding tar= get to table=0A=0AWhen we check the connections it's assign to the native d= rive instead multipath=2E Does anybody has this problem before and how to s= olve it?=0A=0AWe use both Yast and command prompt to connect it with the sa= me results=2E=0A=0ARegards,=0A=0AVictor Echavarry=0ASystem Programmer=0ATec= hnology Systems Operations Division=0AEVERTEC=0A=0A=0A=0D=0A=0D=0A=0D=0A= Victor we had same issue, fix was to add multipath=off to the zipl.conf file and ensure that boot.multipath was started using insserv Tim This email and any files transmitted with it is confidential and intended solely for the person or organisation to whom it is addressed. If you are not the intended recipient, you must not read, copy or disseminate the information or take any action in reliance on it and it would be appreciated if you would also notify the sender by reply email and then delete this email immediately. All messages passing out of this gateway are checked for viruses but Dundee City Council strongly recommends that you check for viruses using your own virus scanner as the Council will not take responsibility for any damage caused as a result of virus infection. -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
Re: selinux training
SELinux used to confuse me and make me angry until I had an epithany: It's really just Mandatory Access Controls that override the normal Unixish permissions. Since I sorta understood the RACFVM MAC concepts I was able to transfer the ideas over to Linux and suddenly all the docs training materials made a lot more sense. Now it's just a royal pain to deal with, instead of being a large blank area on the map that says Thar be dragons here -- Jay Brenneman -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
Re: SLES 11 strange behavior network
On Tuesday, 02/01/2011 at 12:50 EST, Rogério Soares rogerio.soa...@gmail.com wrote: i set up my vswitch to use port group, and give grant permission to guest sles 11 Sp1.. all works okay, but if i give LOGOUT on machine, network not comes back, until i give some network request FROM this machine.. this request can be a ping for example... instantly i give a ping, the nework wake up... anybody already see this behavior ? any clue? this behavior not happens if i give a simple reboot command :-/ here is my definitions of vswitch and port group: 00242 VMLAN MACPREF 026101 00243 MOD PORT GROUP GRPSRV01 JOIN 1D00.P0 1E00.P0 00244 DEFINE VSWITCH VSWSVC01 ETHERNET RDEV 0800.P0 GROUP GRPSRV01 00245 00246 MODIFY VSWITCH VSWSVC01 GRANT DB2P101 on linux, we are currentily using vlan Let's look at some switch theory Switches are smart; they learn what ports own what MAC addresses. In this way, they convert an all-stations broadcast to a single-station (port) broadcast. If they don't see the traffic for a while, they will forget what they learned and go back to an all-stations broadcast. Then, upon seeing an ARP response, they now know what port to send traffic on. In fact, any outbound (from the host) traffic will cause the switch to, uh, switch the MAC-port association. The problem arises when you move a guest from one physical port to another before that forget timer pops. If the guest does not generate any traffic, inbound traffic will go to the wrong port. So, what should Linux do? When Linux brings an interface up, he's supposed to issue an unsolicited (gratuitous) ARP response. When operating in layer 3 mode (VSWITCH or OSA), CP or the OSA issues the grat ARP on your behalf. There are reasons, and ways, to suppress the grat ARP, but that doesn't come into play unless you're doing IP takeover. That is, stealing an IP address from another (failed) adapter. Make sure you do NOT have ARP=no in your Linux network config scripts. I don't know what release of z/VM you are running, but you can also check out http://www.vm.ibm.com/virtualnetwork/mntlvl.html to see if anything applies. I vaguely remember some old APARs dealing with VSWITCHes and grat ARPs. As an aside, one of us is missing something. If you are using VLANs on Linux (vconfig), then I would expect you to have GRANTed PORTTYPE TRUNK VLAN xxx. If you're not using vconfig, then you are not using VLANs inside Linux. You have granted DB2P101 access to the default VLAN (VLAN 1) which is also the default NATIVE VLAN id (which you did not specify). That means the traffic leaves the VSWITCH *untagged* and the physical switch is applying the native VLAN id to the traffic (even if it isn't VLAN 1!). This is not how the VSWITCH is intended to be used. If someone changes the native VLAN id of the switch, you're in a lot of trouble. Alan Altmark z/VM and Linux on System z Consultant IBM System Lab Services and Training ibm.com/systems/services/labservices office: 607.429.3323 alan_altm...@us.ibm.com IBM Endicott -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
Re: SLES 11 strange behavior network
On Wed, 2011-02-02 at 10:40 -0500, Alan Altmark wrote: The problem arises when you move a guest from one physical port to another before that forget timer pops. If the guest does not generate any traffic, inbound traffic will go to the wrong port. So, what should Linux do? When Linux brings an interface up, he's supposed to issue an unsolicited (gratuitous) ARP response. When operating in layer 3 mode (VSWITCH or OSA), CP or the OSA issues the grat ARP on your behalf. We have opened Novell bugzilla 617373 to address the problem of the missing unsolicited (gratuitous) ARP response in SLES11 SP1. Regards, Ursula Braun, IBM Germany -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
Re: SLES 11 strange behavior network
On 2/2/2011 at 04:51 AM, Ursula Braun ubr...@linux.vnet.ibm.com wrote: 1. Overwrite the z/VM-assigned MAC-address with a user-defined MAC-address using an LLADDR-definition line in /etc/sysconfig/network/ifcfg-ethx. Thus the MAC-address does not change after LOGOUT. I would strongly recommend _not_ doing this on a z/VM guest. One of my IBM contacts reported to me that this caused a network outage for z/VM's TCP/IP (random victim, but an important one). Apparently CP doesn't (always?) check to see if a MAC address is in use before handing it out (because Hey, I'm the only one handing them out, right?) and a Linux guest had saved the LLADDR it had been given previously. When TCP/IP started up, then both the Linux guest and TCP/IP were claiming the same MAC. Not good. A PMR has been opened with z/VM support, but I don't know where that stands. For my part, I opened up a bug with SLES development to not save the MAC automatically on a z/VM guest. Mark Post -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
Re: SLES 11 strange behavior network
On Wednesday, 02/02/2011 at 11:42 EST, Mark Post mp...@novell.com wrote: On 2/2/2011 at 04:51 AM, Ursula Braun ubr...@linux.vnet.ibm.com wrote: 1. Overwrite the z/VM-assigned MAC-address with a user-defined MAC-address using an LLADDR-definition line in /etc/sysconfig/network/ifcfg-ethx. Thus the MAC-address does not change after LOGOUT. I would strongly recommend _not_ doing this on a z/VM guest. I was probably remiss in not pointing out that z/VM 6.1 now has the ability to lock down the MAC address assigned to a guest. VMLAN MACPROTECT ON and CP SET NIC USER *|userid vdev MACPROTECT ON When you engage it, the guest can set only the assigned MAC address in the virtual adapter, whether it is set dynamically by CP or statically via the MACID option on the virtual device. That makes overwriting the MAC impossible. For completeness, a new VMLAN USERPREFIX option has been introduced so that you can use different MAC prefixes for static MACIDs. Alan Altmark z/VM and Linux on System z Consultant IBM System Lab Services and Training ibm.com/systems/services/labservices office: 607.429.3323 alan_altm...@us.ibm.com IBM Endicott -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
Re: SLES 11 strange behavior network
On 2/2/11 11:39 AM, Mark Post mp...@novell.com wrote: Apparently CP doesn't (always?) check to see if a MAC address is in use before handing it out (because Hey, I'm the only one handing them out, right?) and a Linux guest had saved the LLADDR it had been given previously. While I feel for the guy who took the outage, this is IMHO exactly what CP *should* do -- assign a random MAC unless explicitly told what one to use, and if explicitly instructed, the consequences are on the user to keep them unique. This problem exists with user-managed MAC addresses everywhere, and the solution is either to not use user-managed MACs or make them guaranteed unique. You manually told it to do something dumb, and it did exactly what it was told. Good CP. Take a donut. For my part, I opened up a bug with SLES development to not save the MAC automatically on a z/VM guest. Right solution. Linux should not be doing this unless you (the user) really mean to use user-managed MAC addresses and are prepared to manage them properly. In fact, why limit this to just Z? It seems an odd thing to do on any platform. Aside from DECnet and SNA support, what still needs the ability to overwrite the MAC address of an interface these days? -- db -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
Re: SLES 11 strange behavior network
On Wednesday, 02/02/2011 at 01:29 EST, David Boyes dbo...@sinenomine.net wrote: Aside from DECnet and SNA support, what still needs the ability to overwrite the MAC address of an interface these days? Are all the MAC-level takeover HA solutions gone? I thought some workload sprayers used MAC spoofing to perform transparent workload transfers. The only other reason I can think of to overwrite the MAC is in order to get a specific DHCP reservation (not the same as static IP). Alan Altmark z/VM and Linux on System z Consultant IBM System Lab Services and Training ibm.com/systems/services/labservices office: 607.429.3323 alan_altm...@us.ibm.com IBM Endicott -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
Re: SLES 11 strange behavior network
Channel bonding would be another. But even then, I wouldn't pick something that is in CP's range to assign. Marcy -Original Message- From: Linux on 390 Port [mailto:LINUX-390@vm.marist.edu] On Behalf Of Alan Altmark Sent: Wednesday, February 02, 2011 10:46 AM To: LINUX-390@vm.marist.edu Subject: Re: [LINUX-390] SLES 11 strange behavior network On Wednesday, 02/02/2011 at 01:29 EST, David Boyes dbo...@sinenomine.net wrote: Aside from DECnet and SNA support, what still needs the ability to overwrite the MAC address of an interface these days? Are all the MAC-level takeover HA solutions gone? I thought some workload sprayers used MAC spoofing to perform transparent workload transfers. The only other reason I can think of to overwrite the MAC is in order to get a specific DHCP reservation (not the same as static IP). Alan Altmark z/VM and Linux on System z Consultant IBM System Lab Services and Training ibm.com/systems/services/labservices office: 607.429.3323 alan_altm...@us.ibm.com IBM Endicott -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/ -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
New Virtualization Cookbook (Redbook) for SLES 11 SP1
Hi, The z/VM and Linux on IBM System z: The Virtualization Cookbook for SLES 11 SP1 is now an official IBM Redbook. See http://www.redbooks.ibm.com/abstracts/sg247931.html?Open Any feedback is welcome. Enjoy. Mike MacIsaac mike...@us.ibm.com (845) 433-7061 -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
