On Tue, Nov 18, 2014 at 06:26:54AM -0700, Eric Blake wrote:
On 11/11/2014 05:42 AM, Daniel P. Berrange wrote:
A previous commit introduced use of locking with invocation of iptables in the viriptables.c module
commit ba95426d6f39aec1da6e069dd7222f7a8c6a5862 Author: Serge Hallyn <serge.hallyn@ubuntu.com> Date: Fri Nov 1 12:36:59 2013 -0500
util: use -w flag when calling iptables
This only ever had effect with the virtual network driver, as it was not wired up into the nwfilter driver. Unfortunately in the firewall refactoring the use of the -w flag was accidentally lost.
This patch introduces it to the virfirewall.c module so that both the virtual network and nwfilter drivers will be using it. It also ensures that the equivalent --concurrent flag to ebtables is used. --- src/util/virfirewall.c | 67 +++++++++++++++++++++++++++++++++++++++++++++++--- src/util/viriptables.c | 2 -- 2 files changed, 63 insertions(+), 6 deletions(-)
With this patch applied, and testing on Fedora 20, I see the following messages at startup of libvirtd:
2014-11-18 13:22:49.979+0000: 31329: info : libvirt version: 1.2.11 2014-11-18 13:22:49.979+0000: 31329: error : virCommandWait:2532 : internal error: Child process (/usr/sbin/iptables -w -L -n) unexpected exit status 2: iptables v1.4.19.1: unknown option "-w" Try `iptables -h' or 'iptables --help' for more information.
2014-11-18 13:22:49.982+0000: 31329: error : virCommandWait:2532 : internal error: Child process (/usr/sbin/ip6tables -w -L -n) unexpected exit status 2: ip6tables v1.4.19.1: unknown option "-w" Try `ip6tables -h' or 'ip6tables --help' for more information.
Do we need a followup patch to avoid logging failures when probing for whether -w works?
+ +static void +virFirewallCheckUpdateLock(bool *lockflag, + const char *const*args) +{ + virCommandPtr cmd = virCommandNewArgs(args); + if (virCommandRun(cmd, NULL) < 0) { + VIR_INFO("locking not supported by %s", args[0]);
Generally, it would be done by passing a non-NULL parameter to virCommandRun and checking the status ourselves (since virCommandRun with a NULL argument logs all non-zero exit).
Ok, I'll look at doing that. I think that's actually what the original code did before it got accidentally lost. Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|