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.
