----- "Jason Wang" <jasowang@xxxxxxxxxx> wrote: > > On Tue, Aug 11, 2009 at 1:16 PM, Michael > Goldish<mgoldish@xxxxxxxxxx> wrote: > > > >> ----- "Jason Wang" <jasowang@xxxxxxxxxx> 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. I agree -- I've just posted a revised patchset that implements solution 1). Let me know if you have any comments. Thanks, Michael -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
