Jan Kiszka wrote:
> > The pcap interface is close to that for ease of configurability, but a
> > bridge would behave better, especially with multiple VMs, and maybe
> > perform better.
> Pcap on Linux suffers from the limitation that injected packets are not
> visible to the host, thus guest<->host communication doesn't work.
> The same is true for PF_PACKET (or does libpcap actually use that
Yes it does.
> Haven't analyzed the reasons in details yet, but I bet
> it's not solvable in user space.
I think that's probably right, and good solutions would be:
- A new option to the kernel bridging to attach a bridge
to an existing net interface in a way which allows the interface's IP
configuration to keep working
- An alternate pcap mode which makes packets visible to the host.
- An "auto-bridging" tap device mode, where it's told which network
interface to bridge to, with an invisible bridge.
Bridging would be better than pcap because it can more easily take
advantage of multiple MAC address support in the network interface
(like macvlan), to filter properly, although I don't know if the
existing Linux bridge code does that. And it more closely resembles
what you'd do with physical machines instead of VMs, which is plug
them into a switch.