qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Qemu-devel] Re: [PATCH 6/7] virtio-net: Add new RX filter controls


From: Jan Kiszka
Subject: [Qemu-devel] Re: [PATCH 6/7] virtio-net: Add new RX filter controls
Date: Tue, 09 Jun 2009 17:42:32 +0200
User-agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv:1.8.1.12) Gecko/20080226 SUSE/2.0.0.12-1.1 Thunderbird/2.0.0.12 Mnenhy/0.7.5.666

Jamie Lokier wrote:
> Daniel P. Berrange wrote:
>> Personally I'd just say the bridge config task is the management tool's 
>> problem to deal with. A mgmt tool UI shouldn't really need to expose 
>> the raw details of physical NICs, bond devices, VLAN devices & bridge 
>> devices to the user. Instead allow them to say 'create a network sharing
>> two physical NICs on VLAN 53', and then have it automagically setup the
>> neccessary individal devices  behind the scenes.
> 
> That's a nice idea, but it depends so intimately on the host's network
> configuration, that it doesn't work in practice (in my experince),
> except in some rather fixed configurations.
> 
> The problem is: when you attach a bridge device, then all the host's
> IP configuration has to be done on the bridge device instead of the
> host's network interfaces.
> 
> That means either:
> 
>     - Host's network configuration (outside the management tool) must
>       create bridges in advance (with one port) _just_ so that VM
>       management can attach to the bridge.  It's hardly transparent.
>       Doesn't work at all with NetworkManager or any ordinary host
>       network configurations, for example.  And you have to do it in
>       advance, not when starting VMs.
> 
>     - Or, the VM management tool must create bridges when VMs are
>       started, and then copy the IP configuration from the host
>       network interface to the bridge, and it must somehow trick the
>       host's DHCP client to moving to the bridge interface, etc.  This
>       doesn't work with NetworkManager either.
> 
> Quite possibly it's a mess because of the way Linux does bridging, but
> still it is.
> 
> I haven't found any solution which works on a laptop running
> NetworkManager or other automatic network binding service.
> 
> For servers with static IPs and simple network configuration it is
> easier, and of course a VM management tool can always handle specific
> cases like that, if told to.  But even on servers, I find if they have
> a complex host network configuration (e.g. policy routing tables),
> adding bridges for the VMs is not something that can be done
> automatically.
> 
> Ideally, there would be a way to add a "bridge for VM" which hangs off
> the edge of the host's networking, instead of disruptively having to
> be in the middle.
> 
> 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
internally?). Haven't analyzed the reasons in details yet, but I bet
it's not solvable in user space.

Jan

-- 
Siemens AG, Corporate Technology, CT SE 2
Corporate Competence Center Embedded Linux




reply via email to

[Prev in Thread] Current Thread [Next in Thread]