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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



----- "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

[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux