From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jason Wang Subject: Re: [Autotest] [KVM-AUTOTEST PATCH 11/12] KVM test: make VMs use a dynamic MAC-IP mapping generated by tcpdump Date: Thu, 13 Aug 2009 00:15:24 +0800 Message-ID: <4A82EA9C.508@redhat.com> References: <1960092437.1769331250006819543.JavaMail.root@zmail05.collab.prod.int.phx2.redhat.com> <826400126.1769931250007364257.JavaMail.root@zmail05.collab.prod.int.phx2.redhat.com> <6ac58f4f0908111007v5d3d917n6bbf4886ea1dc8a3@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Michael Goldish , autotest@test.kernel.org, kvm@vger.kernel.org To: Lucas Meneghel Rodrigues Return-path: Received: from mx2.redhat.com ([66.187.237.31]:47239 "EHLO mx2.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753945AbZHLQMa (ORCPT ); Wed, 12 Aug 2009 12:12:30 -0400 In-Reply-To: <6ac58f4f0908111007v5d3d917n6bbf4886ea1dc8a3@mail.gmail.com> Sender: kvm-owner@vger.kernel.org List-ID: > On Tue, Aug 11, 2009 at 1:16 PM, Michael Goldish wrote: > >> ----- "Jason Wang" wrote: >> >> >>> Hello Michael: >>> Based on our experiences with TAP networking scripts, the >>> verify_mac_ip_pair() could not work well under multiple nics when >>> testing linux guests. The main problem is the policy of multiple >>> interfaces responding in linux, we should take care of the value of >>> net.ipv4.conf.all.arp_ignore. Its default value(0) may cause the host >>> get a mac address that does not configured on the target interface of >>> guest. >>> Maybe we could run a simple 'setup' case for all linux guests to set >>> the value of arp_ignore to 1. >>> What's your opinion? >>> > > Ok, I haven't read this before I finished my review of the patchset. > My test was too simplistic and limited to 1 guest with 1 NIC, that's > why I saw this. > > >> Thanks for pointing this out. >> >> You're right, there seems to be a problem with Linux guests (I tried >> RHEL 3.9). I started RHEL 3.9 with two NICs. At boot time the guest >> got 2 IP addresses and tcpdump collected them properly, but /sbin/arp -n >> listed the addresses as though they were both assigned to the MAC address >> of the first NIC. It's possible that regardless of the NIC I try to >> contact, the reply always comes from eth0, so it seems that both IP >> addresses have the same MAC address. >> >> I don't think we should solve this by messing with the guest, because >> different guests may require different hackish solutions. I think it's >> better to fix the test framework instead. >> The solution you suggested may not work for all Linux guests -- for >> example, on RHEL 3.9 I couldn't find net.ipv4.conf.all.arp_ignore, or any >> arp_ignore. (I did find arp_filter and arp_announce though, and none of >> them helped solve the problem.) >> >> I'm considering 2 solutions: >> >> 1. Do not require the MAC address reported by 'arp -n' to be assigned to >> the NIC we are 'verifiying' -- require it to be assigned to any NIC of >> the guest. This will probably work in all cases. >> > > This already would give us a certain degree of security that we are > talking to who we are planning to. Not sure if we should bother > though. > > >> 2. Stop using verify_mac_ip_pair() altogether. Instead, when destroying >> a VM, remove the MAC addresses of its NICs from the address cache. >> Also, when starting a new test, check each address in the cache and >> make sure it belongs to some living VM, and otherwise remove it. >> This should work in most cases, but _theoretically_ a guest might >> release its IP address during a test, and then the DHCP server might >> assign the same IP address to some other machine, so when we try >> talking to our guest using that IP address, we'll end up talking to >> the other machine. That's exactly the sort of situation >> verify_mac_ip_pair() was meant to prevent, but this situation sounds so >> unlikely to occur, that it might be safe to use this proposed solution. >> > > I also think this is an unlikely situation, unless we are going to > write tests that involve the guest explicitly releasing the IP address > at some point of the test. So the minimalist in me would go for 2). > I prefer 1) than 2) because: It could do some verficiation and should work well under all conditions. Tests who want to test the function of multiple nics could change the policy by themselves. I don't know whether 2) would could work well under all kinds of dhcp server ( consider rebooting , restarting of network or dhcp nack) and all conditions.