> when you say the whole set of chains, do you mean the full firewall config ?
>>Yes - but only for the VMs residing on the node. >>I guess we can optimize that later to only process required parts if it turns >>out to be a performance problem - but I doubt this is a problem. Ok, so I need to rework a little my patches, because currently I don't compute the whole vmbrX-IN vmbrX-OUT chain. (when I setup the tap chain, I test if the jump exist in vmbrX-out and if not exist, I add the jump to tap chain). So, we need to parse all the vm config, check what bridge are used, generate the bridge chains with tap jump, then generate the tap chains. and use checksum to apply only changed chains. ----- Mail original ----- De: "Dietmar Maurer" <[email protected]> À: "Alexandre DERUMIER" <[email protected]> Cc: [email protected] Envoyé: Vendredi 14 Février 2014 18:50:03 Objet: RE: [pve-devel] pve-firewall : iptables V2 > >>Oh, I do not care about crashed VM (why?). > > (I thinked of stale tap chain, that normally we can remove at vm_stop for > example, and not removed if vm crash) We can't do that anyway, because we do not know when a VM crashes. > >>My idea was that we simply compute the whole set of chains we need. > >>Then we compare that with the current ruleset, and only apply the diff > >>(and remove rules which are no longer needed). > > when you say the whole set of chains, do you mean the full firewall config ? Yes - but only for the VMs residing on the node. I guess we can optimize that later to only process required parts if it turns out to be a performance problem - but I doubt this is a problem. > (I'll wait for your patches too see exactly ;) OK, will work on that next week. _______________________________________________ pve-devel mailing list [email protected] http://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
