Re: [Autotest] [KVM-AUTOTEST PATCH 11/12] KVM test: make VMs use a dynamic MAC-IP mapping generated by tcpdump

[Jason Wang <jasowang@redhat.com>]

> On Tue, Aug 11, 2009 at 1:16 PM, Michael Goldish<mgoldish@redhat.com> wrote:
>   
>> ----- "Jason Wang" <jasowang@redhat.com> 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.