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

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

[Michael Goldish]

----- "Dor Laor" <dlaor@redhat.com> wrote:

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

I run tcpdump with a filter ('dst port 68') that makes it output packets
only very rarely (only when some NIC is assigned an IP address).

To make sure tcpdump doesn't significantly impact performance I ran a
few benchmarks (the host is a core 2 duo machine):

- Local iperf: 8.5 Gbits/sec
- Local iperf with tcpdump running (filtered): 8.5 Gbits/sec
- Local iperf with tcpdump running (unfiltered): 6 Gbits/sec
- Local iperf with 4 instances of tcpdump (filtered): 7.3 Gbits/sec
- Local iperf with 4 instances of tcpdump (unfiltered): 3.3 Gbits/sec
- iperf between a Windows VM (virtio) and a host: 240 Mbits/sec (is that normal?)
- Same thing, with tcpdump (filtered): 240 Mbits/sec
- Same thing, with tcpdump (unfiltered): 240 Mbits/sec
- Same thing, with 4 instances of tcpdump (filtered): 240 Mbits/sec
- Same thing, with 4 instances of tcpdump (unfiltered): 200 Mbits/sec

If I understand correctly, this means that running tcpdump with a filter
minimizes the performance penalty involved.

(Note that for KVM tests we only need a single instance of tcpdump, even
when several VMs run at the same time.)

In light of this, do you still fear tcpdump will involve a significant
performance penalty?  Do you think these benchmarks mean anything or
did I make a mistake somewhere that rendered them meaningless?

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

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

[Dor Laor]

On 08/03/2009 04:51 PM, Michael Goldish wrote:
> ----- "Dor Laor"<dlaor@redhat.com>  wrote:
>
>> 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.
>
> I run tcpdump with a filter ('dst port 68') that makes it output packets
> only very rarely (only when some NIC is assigned an IP address).
>
> To make sure tcpdump doesn't significantly impact performance I ran a
> few benchmarks (the host is a core 2 duo machine):
>
> - Local iperf: 8.5 Gbits/sec
> - Local iperf with tcpdump running (filtered): 8.5 Gbits/sec
> - Local iperf with tcpdump running (unfiltered): 6 Gbits/sec
> - Local iperf with 4 instances of tcpdump (filtered): 7.3 Gbits/sec
> - Local iperf with 4 instances of tcpdump (unfiltered): 3.3 Gbits/sec
> - iperf between a Windows VM (virtio) and a host: 240 Mbits/sec (is that normal?)

It's pretty low. There are various issues with iperf and with windows 
registry configurations that can boost it drastically.

> - Same thing, with tcpdump (filtered): 240 Mbits/sec
> - Same thing, with tcpdump (unfiltered): 240 Mbits/sec
> - Same thing, with 4 instances of tcpdump (filtered): 240 Mbits/sec
> - Same thing, with 4 instances of tcpdump (unfiltered): 200 Mbits/sec
>
> If I understand correctly, this means that running tcpdump with a filter
> minimizes the performance penalty involved.
>
> (Note that for KVM tests we only need a single instance of tcpdump, even
> when several VMs run at the same time.)
>
> In light of this, do you still fear tcpdump will involve a significant
> performance penalty?  Do you think these benchmarks mean anything or
> did I make a mistake somewhere that rendered them meaningless?
>

 From the above, it seems like the overhead is low so you can leave the 
tcpdump patch. When we'll do performance testing we should turn it off 
after it traps the dhcp reply.

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

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

[Michael Goldish]

----- "Dor Laor" <dlaor@redhat.com> wrote:

> On 08/03/2009 04:51 PM, Michael Goldish wrote:
> > ----- "Dor Laor"<dlaor@redhat.com>  wrote:
> >
> >> 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.
> >
> > I run tcpdump with a filter ('dst port 68') that makes it output
> packets
> > only very rarely (only when some NIC is assigned an IP address).
> >
> > To make sure tcpdump doesn't significantly impact performance I ran
> a
> > few benchmarks (the host is a core 2 duo machine):
> >
> > - Local iperf: 8.5 Gbits/sec
> > - Local iperf with tcpdump running (filtered): 8.5 Gbits/sec
> > - Local iperf with tcpdump running (unfiltered): 6 Gbits/sec
> > - Local iperf with 4 instances of tcpdump (filtered): 7.3 Gbits/sec
> > - Local iperf with 4 instances of tcpdump (unfiltered): 3.3
> Gbits/sec
> > - iperf between a Windows VM (virtio) and a host: 240 Mbits/sec (is
> that normal?)
> 
> It's pretty low. There are various issues with iperf and with windows
> 
> registry configurations that can boost it drastically.
> 
> > - Same thing, with tcpdump (filtered): 240 Mbits/sec
> > - Same thing, with tcpdump (unfiltered): 240 Mbits/sec
> > - Same thing, with 4 instances of tcpdump (filtered): 240 Mbits/sec
> > - Same thing, with 4 instances of tcpdump (unfiltered): 200
> Mbits/sec
> >
> > If I understand correctly, this means that running tcpdump with a
> filter
> > minimizes the performance penalty involved.
> >
> > (Note that for KVM tests we only need a single instance of tcpdump,
> even
> > when several VMs run at the same time.)
> >
> > In light of this, do you still fear tcpdump will involve a
> significant
> > performance penalty?  Do you think these benchmarks mean anything
> or
> > did I make a mistake somewhere that rendered them meaningless?
> >
> 
>  From the above, it seems like the overhead is low so you can leave
> the 
> tcpdump patch. When we'll do performance testing we should turn it off
> after it traps the dhcp reply.

OK, that's very easy to do -- the test just has to call something like
env["tcpdump"].close() before running iperf.

BTW, can iptables decode DHCP packets too (like tcpdump does), or can
it just 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
> >>> --
> >>> 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

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

[Michael Goldish]

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

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

[Dor Laor]

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

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

[Michael Goldish]

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

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

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

[Dor Laor]

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