Re: [KVM-AUTOTEST PATCH 0/12] TAP support (and a few other small things)

[Dor Laor <dlaor@redhat.com>]

On 08/03/2009 12:39 PM, Michael Goldish wrote:
> ----- "Dor Laor"<dlaor@redhat.com>  wrote:
>
>> tcpOn 08/03/2009 02:58 AM, Michael Goldish wrote:
>>> Here's my proposed TAP solution:
>>> - The user specifies MAC ranges and may or may not specify
>> corresponding IP
>>> ranges.
>>> - VMs are always given MAC addresses from the user specified MAC
>> ranges.
>>> - MAC address ranges must be unique to each host running KVM tests
>> -- there
>>> must be no overlap between them.
>>> - If corresponding IP ranges are specified as well, the system will
>> use them
>>> when trying to communicate with guests.
>>> - If corresponding IP ranges are not specified, tcpdump will be used
>> to listen
>>> to DHCP traffic and dynamically detect the right IP addresses.
>> There's also a
>>> flag that can force this behavior.
>> This is pretty nice patch set and it's nice and friendly to hook the
>> assigned ip address.
>> Maybe instead of using tcpdump you can add a specific ip tables rule
>> to
>> trap dhcp replies and log them?
>
> What are the advantages compared to tcpdump? Is it easier?
> If you look at the tcpdump patch you'll see it's quite short.
> Most of the code in this set is not related to tcpdump but rather to
> host specific static MAC-IP mapping and other related things.
> To me the iptables idea sounds a little more complex especially since
> we'll have to deal with host specific configuration -- I'm not even sure
> all hosts run a firewall. What do you think?

iptables config might be a bit harder but on the same scale..
If you plan to constantly run tcpdump in the background iptables hook 
will be much cheaper.

>
>>> - tcpdump will run in the background at all times, and collect
>> MAC-IP pairs
>>> as soon as they are assigned by the DHCP server.  This is useful
>> for
>>> NIC hotplugging (where IP addresses are assigned during the test
>> itself) and
>>> generally for misbehaving guests or DHCP servers (restarting network
>> services
>>> during the test, using very short lease times).
>>> - It is up to the user to create the actual bridge for TAP devices;
>> the
>>> qemu-ifup script included in one of the patches only adds the TAP
>> interface to
>>> an existing bridge.  The user should modify this script or create a
>> bridge
>>> some other way.
>>>
>>> This works very well on two hosts I tried, but I'm not entirely sure
>> it will
>>> work in all cases -- please let me know what you think.
>>>
>>> (I remember Jason Wang mentioned that tcpdump doesn't always catch
>> all the
>>> required traffic, or that it might somehow depend on the DHCP server
>> -- anyone
>>> willing to comment on that?)
>>>
>>> The following patches have been tested with a few KVM tests (boot,
>> reboot,
>>> stress_boot, migration) with both TAP and user mode, but they could
>> probably
>>> use more testing (maybe with Python 2.6?), so if anyone is willing
>> to help
>>> with that I'd appreciate it very much.
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe kvm" in
>>> the body of a message to majordomo@vger.kernel.org
>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html