From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Michael S. Tsirkin" Subject: Re: TODO item: guest programmable mac/vlan filtering with macvtap Date: Mon, 1 Nov 2010 13:29:43 +0200 Message-ID: <20101101112943.GA28908@redhat.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: Arnd Bergmann , kvm@vger.kernel.org, qemu-devel@nongnu.org To: Dragos Tatulea Return-path: Received: from mx1.redhat.com ([209.132.183.28]:52989 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757284Ab0KAL3x (ORCPT ); Mon, 1 Nov 2010 07:29:53 -0400 Content-Disposition: inline In-Reply-To: Sender: kvm-owner@vger.kernel.org List-ID: On Mon, Nov 01, 2010 at 11:48:23AM +0100, Dragos Tatulea wrote: > > 1. add a secondary mac (or third, etc) address to the guest virtio-= net > > interface. > Maybe I misunderstood this. Is it just setting another mac on the > guest virtio-net interface? Well, yes, that's also not possible at the moment. Or e.g. set more than one mac per virtio-net device using macvlan. > > > > 4. the above stuff must be controllable by host admin > > =A0- Well, for this there are a few options: > > =A0 =A0> admin switch that allows the guest user to add macs > > =A0 =A0> preconfig allowed MAC's in mactap (or qemu config) for the= guest user > > =A0 =A0> allow/disallow command for user in qemu (although this doe= sn't > > seem to be supported) > > > Well, on a second thought, qemu capabilities should be just fine, rig= ht? >=20 > -- Dragos At some level, although I think we also want a way to disable access that qemu can't override unless it has net admin capability. --=20 MST