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. > 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
