
On Tue, Mar 23, 2010 at 10:54:06AM -0400, stefanb@us.ibm.com wrote:
One comment about the instantiation of the rules: Since the XML allows to create nearly any possible combination of parameters to ebtables or iptables commands, I haven't used the ebtables or iptables wrappers. Instead, I am writing ebtables/iptables command into a buffer, add command line options to each one of them as described in the rule's XML, write the buffer into a file and run it as a script. For those commands that are not allowed to fail I am using the following format to run them:
cmd="ebtables <some options>" r=`${cmd}` if [ $? -ne 0 ]; then echo "Failure in command ${cmd}." exit 1 fi
cmd="..." [...]
If one of the command fails in such a batch, the libvirt code is going pick up the error code '1', tear down anything previously established and report an error back. The actual error message shown above is currently not reported back, but can be later on with some changes to the commands running external programs that need to read the script's stdout.
I've tried out this patch series, but not entirely sure whether it is working correctly, since there are lots of errors in the libvirt debug logs. I have a guest <interface type='network'> <mac address='52:54:00:4d:c8:5f'/> <source network='default'/> <filterref filter='demofilter4'> <parameter name='IP' value='9.59.241.151'/> </filterref> <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/> </interface> And demofilter4 is setup as: <filter name='demofilter4' chain='root'> <uuid>d33d17bf-0198-6b89-0b03-55abba1eae7f</uuid> <filterref filter='no-mac-spoofing'/> <filterref filter='no-mac-broadcast'/> <filterref filter='no-arp-spoofing'/> <filterref filter='allow-dhcp'> <parameter name='DHCPSERVER' value='10.0.0.1'/> </filterref> </filter> The filter it references here are the XML examples you sent out previously The guest starts without error, and I get a lot of things in the ebtables 'nat' table, but nothing in the 'filter' table - is that expected ? # ebtables -t nat -L Bridge table: nat Bridge chain: PREROUTING, entries: 1, policy: ACCEPT -i vnet0 -j I-vnet0 Bridge chain: OUTPUT, entries: 0, policy: ACCEPT Bridge chain: POSTROUTING, entries: 1, policy: ACCEPT -o vnet0 -j O-vnet0 Bridge chain: I-vnet0, entries: 2, policy: ACCEPT -p IPv4 -j I-vnet0-ipv4 -p ARP -j I-vnet0-arp Bridge chain: O-vnet0, entries: 2, policy: ACCEPT -p IPv4 -j O-vnet0-ipv4 -p ARP -j O-vnet0-arp Bridge chain: I-vnet0-ipv4, entries: 3, policy: ACCEPT -s ! 52:54:0:4d:c8:5f -j DROP -p IPv4 --ip-src 0.0.0.0 --ip-dst 255.255.255.255 --ip-proto udp --ip-sport 68 --ip-dport 67 -j ACCEPT -d Broadcast -j DROP Bridge chain: O-vnet0-ipv4, entries: 1, policy: ACCEPT -p IPv4 --ip-src 10.0.0.1 --ip-proto udp --ip-sport 67 --ip-dport 68 -j ACCEPT Bridge chain: I-vnet0-arp, entries: 5, policy: ACCEPT -p ARP --arp-mac-src ! 52:54:0:4d:c8:5f -j DROP -p ARP --arp-ip-src ! 9.59.241.151 -j DROP -p ARP --arp-op Request -j ACCEPT -p ARP --arp-op Reply -j ACCEPT -j DROP Bridge chain: O-vnet0-arp, entries: 5, policy: ACCEPT -p ARP --arp-op Reply --arp-mac-dst ! 52:54:0:4d:c8:5f -j DROP -p ARP --arp-ip-dst ! 9.59.241.151 -j DROP -p ARP --arp-op Request -j ACCEPT -p ARP --arp-op Reply -j ACCEPT -j DROP The libvirt logs show a bunch of shell erorrs - see the attachment to this mail. Are these errors to be expected, or are they actual errors ? Also, I'm wondering if it is possible to include 'libvirt-' in the custom ebtables/iptables chains that we create ? I think that would be useful for sysadmins who might be surprised at where all these rules are coming from. From the code it looks like we have a fairly low size limit on the possible chain names, but I think at least for the first two chains we ought to be able to get 'libvirt-' prefix in there. Or perhaps instead of adding the per-VIF chains straight to PREROUTING/POSTROUTING, have an unconditional jump to a libvirt specific chain. So either have Bridge chain: PREROUTING, entries: 1, policy: ACCEPT -i vnet0 -j libvirt-I-vnet0 Bridge chain: OUTPUT, entries: 0, policy: ACCEPT Bridge chain: POSTROUTING, entries: 1, policy: ACCEPT -o vnet0 -j libvirt-O-vnet0 Or the slightly more complex Bridge chain: PREROUTING, entries: 1, policy: ACCEPT -j libvirt-I Bridge chain: OUTPUT, entries: 0, policy: ACCEPT Bridge chain: POSTROUTING, entries: 1, policy: ACCEPT -j libvirt-O Bridge chain: libvirt-I, entries: 1, policy: ACCEPT -i vnet0 -j I-vnet0 Bridge chain: OUTPUT, entries: 0, policy: ACCEPT Bridge chain: libvirt-O, entries: 1, policy: ACCEPT -o vnet0 -j O-vnet0 Regards, Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://deltacloud.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|