Re: [libvirt] [PATCH v3 00/14] Network filtering (ACL) extensions for libvirt

"Daniel P. Berrange" <berrange(a)redhat.com&gt; wrote on 03/25/2010 07:37:14 AM: XML, commands The errors in the debugging log are due to attempts to cleanup user-defined tables that do not exist. Though attempting to clean them up gets the system into a well known start state. The errors could be avoided with a sequence of checking for existence of the user-defined chain first and then try to flush and delete them, but it's faster not to do so. previously ebtables Yes, this is correct. The nat table handles the filtering correctly and with the PREROUTING chain we can filter for traffic coming from the VM (that becomes incoming to the host - prefix letter 'I') and in the POSTROUTING chain traffic going to the VM (outgoing from the host - prefix letter 'O'). ACCEPT this They are due to attempted cleanups that try to cleanup user-defined tables that did not exist on your system, however. As said, this gets the system into a well known start-out state so that those user-defined ebtables tables can be established with rules. As seen above, every interface gets a 'tree' of user-defined tables. Following the chain identifier in the above XML <filter name='demofilter4' chain='root'> <uuid>d33d17bf-0198-6b89-0b03-55abba1eae7f</uuid> [...] which can be either left out entirely for meaning of 'root', or be 'root' explicitly or have the values 'arp' or 'ipv4'. The patterns of the user-defined ebtables tables is due to 32 byte size restrictions (including trailing 0) as follows: <one letter prefix>-<name of the interface>-<filter chain identifier>: This then leads to I-vnet0 and I-vnet0-ipv4 etc. as shown above. However, the tricky part are updates of filters. You can, using virsh-define, update any filter while it is being used by running VMs. For updates I decided not to compare the current filter tree against the new one, calculating 'diffs' for the rules and remove rules that don't exist in the new one along with user defined tables that may not exist anymore etc., which would be much more complicated. Instead, I am completely rebuilding the filter tree. So, a temporary filter tree is established with user-defined names following the above pattern while the current filter tree is still active. However, the prefixes are different. So the temporary filter tree would have user-defined tables named J-vnet0 and J-vnet0-ipv4 etc. where all the rules are established. Then, while the 'old' filter tree is active, the new one is anchored, leading to entries like this one: Bridge chain: PREROUTING, entries: 1, policy: ACCEPT -i vnet0 -j I-vnet0 -i vnet0 -j J-vnet0 Yes, temporarily you would have two parallel filter trees for an interface, but the old one is still active. Then comes the switch-over to the new tree where the old filter tree is un-anchored, leading to this situation: Bridge chain: PREROUTING, entries: 1, policy: ACCEPT -i vnet0 -j J-vnet0 Now all possible chains starting with prefix I-vnet0-<XYZ> are flushed and deleted. In the subsequent step I rename the filter tree starting with J-<vnet0>-<XYZ> to I-<vnet0>-<XYZ> leading to Bridge chain: PREROUTING, entries: 1, policy: ACCEPT -i vnet0 -j I-vnet0 which is where we want to be so that the next update can do the same procedure again. I have made some changes to the core patch (part 11) that split up the application of new filter rules into 3 different (interface) functions, for application of new rules, switch over + tear down of old, or tear down of new in case an error happened. custom Both is possible with the first one resulting in being more efficient. I'll try to make that change. Regards, Stefan http://people.redhat.com/berrange/:| http://deltacloud.org:| http://search.cpan.org/~danberr/:| 9505 :|