On Thu, Oct 15, 2009 at 05:48:19PM +0200, Michael S. Tsirkin wrote: > On Thu, Oct 15, 2009 at 10:18:18AM -0500, Anthony Liguori wrote: > > Michael S. Tsirkin wrote: > >> On Thu, Oct 15, 2009 at 08:32:03AM -0500, Anthony Liguori wrote: > >> > >>> Michael S. Tsirkin wrote: > >>> > >>>> On Wed, Oct 14, 2009 at 05:53:56PM -0500, Anthony Liguori wrote: > >>>> > >>>>> I would be much more inclined to consider taking raw and > >>>>> improving the performance long term if guest<->host networking > >>>>> worked. This appears to be a fundamental limitation though and > >>>>> I think it's something that will forever plague users if we > >>>>> include this feature. > >>>>> > >>>> In fact, I think it's fixable with a raw socket bound to a macvlan. > >>>> Would that be enough? > >>>> > >>> What setup does that entail on the part of a user? Wouldn't we be > >>> back to square one wrt users having to run archaic networking > >>> commands in order to set things up? > >>> > >> > >> Unlike bridge, qemu could set up macvlan without disrupting > >> host networking. The only issue would be cleanup if qemu > >> is killed. > >> > > > > But this would require additional features in macvlan, correct? > > Not sure: what is the "this" that you are talking about. > It can already be set up without disturbing host networking. > > > This also only works if a guest uses the mac address assigned to it, > > correct? If a guest was bridging the virtual nic, this would all come > > apart? > > Hmm, you could enable promisc mode, but generally this is true: > if you require bridging, use a bridge. Just to clarify this statement: if bridge in guest does not configure mac filtering on guest uplink (linux bridge by default does not do this now, OTOH macvlan does), bridge in host will perform better in this setup because it learns macs from traffic and does mac filtering in host. > > Regards, > > > > Anthony Liguori -- 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
