From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dor Laor Subject: Re: [KVM-AUTOTEST PATCH 0/12] TAP support (and a few other small things) Date: Mon, 03 Aug 2009 14:57:14 +0300 Message-ID: <4A76D09A.3020304@redhat.com> References: <1213848272.1356721249292376081.JavaMail.root@zmail05.collab.prod.int.phx2.redhat.com> Reply-To: dlaor@redhat.com Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: autotest@test.kernel.org, kvm@vger.kernel.org, Paolo Bonzini To: Michael Goldish Return-path: Received: from mx2.redhat.com ([66.187.237.31]:57267 "EHLO mx2.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752537AbZHCL6E (ORCPT ); Mon, 3 Aug 2009 07:58:04 -0400 In-Reply-To: <1213848272.1356721249292376081.JavaMail.root@zmail05.collab.prod.int.phx2.redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: On 08/03/2009 12:39 PM, Michael Goldish wrote: > ----- "Dor Laor" 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