Re: [libvirt] Dumping network traffic
On 07/23/2012 10:26 AM, Hendrik Schwartke wrote:
I'm currently working on a feature that dumps the network traffic
of a virtual interface over the streaming api of libvirt.
The goal is to offer the possiblity to debug network related problems of guests without
the need to have access to a shell on the host.
E.g. "virsh iface-dumptraffic virbr0 icmp | tcpdump -n -r -" prints all icmp
traffic on virbr0 to stdout.
The code below is only a proof of concept, but it should be possible to recognize what I
have in mind and how I want to implement it.
So I would appreciate any comments on that!
It's definitely interesting functionality, but putting it in
netcf_driver.c doesn't seem like the right place, since it doesn't use
any netcf functionality, and could just as easily be made to work
without it. On the other hand, since (the way you've implemented it) it
is related to host interfaces, it kind of makes logical sense for it to
be named virInterface<something>, and the backend of all those commands
is currently in netcf_driver.c.
When I first saw the patch, my initial reaction was that it may be
better suited to making two separate APIs, virNetworkDumpTraffic(),
which would have the same functionality you're proposing, but would
determine the name of the device to dump by looking in the config for
the named network, and virDomainDumpTraffic() which would dump the
network traffic for a specific domain (conceptually this should relieve
the programmer from learning the name of the physical device). However,
I then realized that:
1) in the case of a network, not all networks even have a bridge device
associated with them - some only have a pool of physical devices, and
those devices can't even be tapped into anyway (macvtap devices don't
support iptables, ebtables, or tapping in for tcpdump).
2) in the case of a domain, there could be multiple <interface>s, and
they have no permanent logical name, so the user of this new API would
still end up needing to grab the XML for the domain and parse out the
<target dev='xxx'/> for each interface, and that interface name would in
the end be a name on the host not the guest (so the name of the domain
would really be irrelevant to this new API), *AND* again any
type='direct' (macvtap) or type='hostdev' (PCI passthrough) interface
could not be tapped.
So, I have no good alternative - no solutions here, just maybe fodder
for more discussion. (hmm, maybe this new functionality could be put in
a separate .c file that is linked to netcf_driver.c (and would
theoretically be linked to any other interface driver that needed the
same implementation of the same functionality).
(BTW, I've often thought about a magical "libvirt networking
troubleshooter" that would pick through host config, /proc entries, and
traffic dumps at all the tappable spots along the network plumbing of a
guest and try to determine the root of problems, then just spit out an
answer. The type of functionality you're proposing could actually help
make that a reality (although in the end the results may not be worth
the effort :-/)