On Tue, Apr 26, 2016 at 11:06:23AM -0400, Laine Stump wrote: > On 04/26/2016 04:15 AM, Daniel P. Berrange wrote: > > On Mon, Apr 25, 2016 at 01:48:49PM -0400, Laine Stump wrote: > >> We still periodically get requests to allow custom iptables rules for > >> libvirt virtual networks (or, more commonly, a mode where libvirt simply > >> leaves iptables alone, not adding or removing anything), and it's been a > >> nagging item on my to-do list for a very long time. The problem is that, > >> although the amount of code required to support *any* solution is very > >> small, it's one of those things without a single obvious "only" way to do > >> it. Anyway, I'm going to take one more stab at it. > >> > >> > >> First, some background points: > >> > >> * For <forward mode='nat'> libvirt's iptables rules are essential to the > >> operation of the forwarding, so we shouldn't mess with that. > >> > >> * For [no forward mode], libvirt's iptables rules are a part of what keeps > >> the network isolated from the rest of the network, so we shouldn't mess with > >> that either. > >> > >> * For <forward mode='route'> we currently allow all outgoing and incoming as > >> long as it is to/from the IP address range defined for the network. > >> > >> So we really want something that can be used only for <forward mode='route'> > >> > >> I can see 3 different possibilities: > >> > >> 1) a new forward mode which is just like 'route', but doesn't add any > >> iptables rules. (what to call it though? "filterless-route"? Too long and > >> ugly :-/) > > I'd suggest this and just call it mode='bare' or mode='open', to avoid > > implying any specific semantics about the connectivity. > > Thinking about this more, I'm having disturbing memories of trying to > combine multiple knobs into a single attribute in the past, only to have > it backfire later (I can't recall anything specific though) - for > example although I say right now that there's no reason to skip adding > rules for isolated or nat networks, we may come up with a valid use case > in the future. For that reason, I think it may be safer to add: > > <forward mode='route' filter='none'/> I would probably consider using sub-element <filter mode='none'/> or the mode='manual'. One example of that design backfiring right now is the <graphcis> device and it's listen attribute and listen sub-elements. I'm working on patches to move also ports into the listen elements and introducing new types of listen elements and there has to be extra code for backward compatibility. Pavel > > (or "manual" as Cole suggested). That way it's still obvious from mode > that the traffic will be routed to other networks, and it will be > possible to use the filter attribute for other modes (or add other > filter settings even for mode='route') in the future. (Validation would > be added to make sure that the filter attribute isn't set for any mode > other than route). Does that make sense? -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list