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 12:24:19 +0300 Message-ID: <4A76ACC3.5050800@redhat.com> References: <1249257501-19337-1-git-send-email-mgoldish@redhat.com> Reply-To: dlaor@redhat.com Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; 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]:34027 "EHLO mx2.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751241AbZHCJZJ (ORCPT ); Mon, 3 Aug 2009 05:25:09 -0400 In-Reply-To: <1249257501-19337-1-git-send-email-mgoldish@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: 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? > - 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