Ask IBM about VM65104 when you call. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose, or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation.
-----Original Message----- From: Linux on 390 Port [mailto:[email protected]] On Behalf Of David Boyes Sent: Thursday, September 20, 2012 11:12 AM To: [email protected] Subject: Re: [LINUX-390] Question on z/VM VMRELOCATION of SLES 11 SP1 guest Can't test this at the moment, but do the system logs tell you if the relocation generates a disconnect/reconnect event for the interface in question? IMHO, if it doesn't, then it should, since you're doing the equivalent of unplugging the machine, moving it, and then reconnecting it. Even if it's reconnecting to the same VLAN, the initial ARP to make sure you own the associated IP address should happen to avoid a race where a duplicate IP address could come online during the migration. Try running arping on the Linux machine via the 3270 console after the migration. If that fixes the problem (and it probably will), configure your Linux guests to generate a gratuitous ARP when the network interface state changes. That should force the FW to forget the old ARP entry and pickup the new one. Why the gratuitous ARP is no longer the default is still a mystery (at least to me, anyway) -- I can't conceive of a case where this would be the wrong behavior, and a ARP flood is not likely to be caused by a loose connector in this scenario (all virtual, all the time). There is probably a good argument that the VM migration code could/should force a proxy ARP for a guest when it gets migrated, though. It has enough information to do it (the old and new virtual MACs and the associated real OSA MACs) and that would at least force other devices to reevaluate any caches that might be present, even if the result ends up with the original configuration. Worth a call to the support center to discuss, anyway.
