On 08/03/2009 12:39 PM, Michael Goldish wrote:
----- "Dor Laor"<dlaor@xxxxxxxxxx> 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@xxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
