Hi there!

I would like to add network filters [1] to accept various kind of
incoming traffics (e.g. HTTP) and thus I read the documentation at:

  <http://libvirt.org/formatnwfilter.html>

[1] despite myself not being a firewall guru, I fail to understand why
    we need yet another format to define filters instead of using the
    iptables syntax by default or adding something like the ifupdown's
    options (in this case post-up and pre-down)...

However, adding a simple filter like the following causes an error:
=====
# cat /etc/libvirt/nwfilter/allow-http.xml
<filter name='allow-http' chain='ipv4'>
  <rule action='accept' direction='in' >
    <tcp dstportstart='80' />
  </rule>
</filter>

# grep allow-http /etc/libvirt/qemu/shelob.pca.it.xml
      <filterref filter='allow-http'/>

# service libvirt-bin restart

# less /var/log/syslog
[...]
Aug  5 16:27:55 mantissa libvirtd: 16:27:55.999: error : virRunWithHook:857 : \
 internal error '/sbin/iptables --table filter --delete INPUT --in-interface virbr0 \
 --protocol udp --destination-port 69 --jump ACCEPT' exited with non-zero status 1 \
 and signal 0: iptables: Bad rule (does a matching rule exist in that chain?).#012
Aug  5 16:27:56 mantissa libvirtd: 16:27:56.404: error : ebiptablesDriverInit:3416 : \
 internal error essential tools to support ip(6)tables firewalls could not be located
Aug  5 16:27:56 mantissa libvirtd: 16:27:56.406: warning : qemudStartup:1832 : \
 Unable to create cgroup for driver: No such device or address
Aug  5 16:27:56 mantissa libvirtd: 16:27:56.494: warning : qemudParsePCIDeviceStrs:1422 : \
 Unexpected exit status '1', qemu probably failed
Aug  5 16:27:56 mantissa libvirtd: 16:27:56.498: error : _iptablesCreateRuleInstance:1113 : \
 internal error cannot create rule since iptables tool is missing.
Aug  5 16:27:56 mantissa kernel: [312791.663024] device vnet0 entered promiscuous mode
Aug  5 16:27:56 mantissa kernel: [312791.664044] virbr0: topology change detected, propagating
Aug  5 16:27:56 mantissa kernel: [312791.664047] virbr0: port 1(vnet0) entering forwarding state
Aug  5 16:27:56 mantissa kernel: [312791.682240] virbr0: port 1(vnet0) entering disabled state
Aug  5 16:27:56 mantissa kernel: [312791.701260] device vnet0 left promiscuous mode
Aug  5 16:27:56 mantissa kernel: [312791.701262] virbr0: port 1(vnet0) entering disabled state
Aug  5 16:27:56 mantissa libvirtd: 16:27:56.596: error : qemuAutostartDomain:827 : \
 Failed to autostart VM 'shelob.pca.it': internal error cannot create rule since iptables tool is missing.
Aug  5 16:27:56 mantissa libvirtd: 16:27:56.654: warning : lxcStartup:1900 : \
 Unable to create cgroup for driver: No such device or address
=====

The first error is #592177 (with its clones #615907 and #626166), the
other errors about essential or iptables tools missing are still
puzzling my brain for an explication :-|

NB, I do not have install-recommends on by default, but I have both
    ebtables and iptables installed.  I tried installing libxml2-utils,
    but the error is still present.

Thx, bye,
Gismo / Luca

found 636712 0.9.3-4
thanks

Hi there!
[...]

On my up-to-date sid, the error is the same, thus updating the version
information for this bug report and also providing at the end the full
output from `reportbug --template libvirt-bin`.

This is true for my sid as well, i.e. both ebtables and iptables are
installed, but not libxml2-utils nor gawk.

Thx, bye,
Gismo / Luca

Hi Luca,

It works here with a very similar rule for ssh accept:

Chain FI-vnet0 (1 references)
target     prot opt source               destination
RETURN     tcp  --  0.0.0.0/0            0.0.0.0/0            tcp spt:22 state ESTABLISHED ctdir ORIGINAL

Chain FO-vnet0 (1 references)
target     prot opt source               destination
ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0            tcp dpt:22 state NEW,ESTABLISHED ctdir REPLY

Chain HI-vnet0 (1 references)
target     prot opt source               destination
RETURN     tcp  --  0.0.0.0/0            0.0.0.0/0            tcp spt:22 state ESTABLISHED ctdir ORIGINAL

Could you check /var/log/libvirt/libvirtd.log? If there's nothing
interesting in there try running

/etc/init.d/libvirt-bin stop
LIBVIRT_DEBUG=1 libvirtd -v

and attach the output to this bug please.

#592177 should be fixed with 0.9.4~rc1. 0.9.4 is about to be uploaed to
unstable pending a LFS fix.
Cheers,
 -- Guido

Getting the variable replacements and priorities implemented is easier
with XML. I agree that having this better integrated into ifupdown would
be nice though.
Cheers,
 -- Guido

Hi there!
[...]

Output attached, also for /var/log/syslog (0.8.3-5+squeeze2, please tell
me if you want the one from 0.9.4~rc1-1).

After some debugging, I think the problem is the missing gawk, given
that in libvirt-0.9.3/src/nwfilter/nwfilter_ebiptables_driver.c we have:

0.9.x, as soon as this bug will be solved.

Thx, bye,
Gismo / Luca

We believe that the bug you reported is fixed in the latest version of
libvirt, which is due to be installed in the Debian FTP archive:

libvirt-bin_0.9.4-1_i386.deb
  to main/libv/libvirt/libvirt-bin_0.9.4-1_i386.deb
libvirt-dev_0.9.4-1_i386.deb
  to main/libv/libvirt/libvirt-dev_0.9.4-1_i386.deb
libvirt-doc_0.9.4-1_all.deb
  to main/libv/libvirt/libvirt-doc_0.9.4-1_all.deb
libvirt0-dbg_0.9.4-1_i386.deb
  to main/libv/libvirt/libvirt0-dbg_0.9.4-1_i386.deb
libvirt0_0.9.4-1_i386.deb
  to main/libv/libvirt/libvirt0_0.9.4-1_i386.deb
libvirt_0.9.4-1.debian.tar.gz
  to main/libv/libvirt/libvirt_0.9.4-1.debian.tar.gz
libvirt_0.9.4-1.dsc
  to main/libv/libvirt/libvirt_0.9.4-1.dsc
libvirt_0.9.4.orig.tar.gz
  to main/libv/libvirt/libvirt_0.9.4.orig.tar.gz
python-libvirt_0.9.4-1_i386.deb
  to main/libv/libvirt/python-libvirt_0.9.4-1_i386.deb



A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 636712@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Guido Günther <agx@sigxcpu.org> (supplier of updated libvirt package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@debian.org)
Format: 1.8
Date: Tue, 09 Aug 2011 16:41:24 +0200
Source: libvirt
Binary: libvirt-bin libvirt0 libvirt0-dbg libvirt-doc libvirt-dev python-libvirt
Architecture: source all i386
Version: 0.9.4-1
Distribution: experimental
Urgency: low
Maintainer: Debian Libvirt Maintainers <pkg-libvirt-maintainers@lists.alioth.debian.org>
Changed-By: Guido Günther <agx@sigxcpu.org>
Description:
 libvirt-bin - programs for the libvirt library
 libvirt-dev - development files for the libvirt library
 libvirt-doc - documentation for the libvirt library
 libvirt0   - library for interfacing with different virtualization systems
 libvirt0-dbg - library for interfacing with different virtualization systems
 python-libvirt - libvirt Python bindings
Closes: 636712 636965
Changes:
 libvirt (0.9.4-1) experimental; urgency=low
 .
   * [a92d03e] New upstream version 0.9.4
   * [76f0333] Run tests verbosely to ease error diagnostics
   * [f4e7d0b] Work around ICE on m68k.
     Thanks to Thorsten Glaser
   * [ac6e760] Add directories chown'ed in the postinst.
     Thanks to Houmehr Aghabozorgi for the report (Closes: #636965)
   * [194722a] Simplify netcat probe and adjust testcase output to reduce
     number of failing testcases.
   * [05e5a06] Use libyajl QEMU JSON support
   * [e7934f7] Use libpcap for ip address learning support
   * [6661730] Readd LFS support
   * [17d831b] Don't require gawk for a simple print expression
     (Closes: #636712)
Checksums-Sha1:
 edce19233031d58c1ed700a444d3541d8739e565 1990 libvirt_0.9.4-1.dsc
 29e81c972ca7c3e73f4cecf84e77f68739ef00a2 16643543 libvirt_0.9.4.orig.tar.gz
 1ec3fc59de769f844cdc33ea856188a01f726e88 78246 libvirt_0.9.4-1.debian.tar.gz
 53aac6eca18b49312cc4de42ff160c3ede58f58b 1731642 libvirt-doc_0.9.4-1_all.deb
 f2f9b3203091cb1fd0a4f5c13e3e45257118aaa8 1724066 libvirt-bin_0.9.4-1_i386.deb
 5d51ad9385f536f0f1836f31b396492fdb8f6163 1636362 libvirt0_0.9.4-1_i386.deb
 1a9366d54627cb568ef67ea29476c1670408c23e 4639504 libvirt0-dbg_0.9.4-1_i386.deb
 847226baec54f6c13a74ab7c813a0abb23ffc751 1956410 libvirt-dev_0.9.4-1_i386.deb
 1590f28506bf8d6431069e045fc13f9dc32fc04c 843916 python-libvirt_0.9.4-1_i386.deb
Checksums-Sha256:
 83c2220ab4f9ab5e7fb9982a6b50de92f817f6cc3fa71b9178caf32596e30bef 1990 libvirt_0.9.4-1.dsc
 e76c026646ae4885b162bf711b854f36195f93538d6fcbee48479c2354a342af 16643543 libvirt_0.9.4.orig.tar.gz
 8a06ce3259fb647d6cd9f396692906c7d278c90e362958639bfbe93b7c8c9d35 78246 libvirt_0.9.4-1.debian.tar.gz
 cb0e5f694c019ced4d2392142278c0589e478cb9dce35f88080a20a975b31ea1 1731642 libvirt-doc_0.9.4-1_all.deb
 8a32d92f54e2e21f27c84d04e2ed522adb80f9829a495df0eb9ca17a4e678fb2 1724066 libvirt-bin_0.9.4-1_i386.deb
 da316a5176bb72cc7520337ed0b726fc1e7e5ea842df6c002e5a212fe5b45c61 1636362 libvirt0_0.9.4-1_i386.deb
 35a21c0ff0972ca6b0cb001857aaaec8f6e2e3f49935ef5608f35457ed69cd09 4639504 libvirt0-dbg_0.9.4-1_i386.deb
 5aeab74eec21a6db42ee54f6ace46368314117f9cd0b0663d33787ba2b349186 1956410 libvirt-dev_0.9.4-1_i386.deb
 575a7e2977207f2abbe7fa4d9867e84eb4c366ef3e04d7cbfaa02bf81d6712f9 843916 python-libvirt_0.9.4-1_i386.deb
Files:
 ad2bc326b58e1afb8ff7ab759942a5d5 1990 libs optional libvirt_0.9.4-1.dsc
 86b411b11bd23d4af20611699f372af7 16643543 libs optional libvirt_0.9.4.orig.tar.gz
 528e8879f3ecacfb322132822b87c964 78246 libs optional libvirt_0.9.4-1.debian.tar.gz
 a0def953ab8f73286787e0386c03d90d 1731642 doc optional libvirt-doc_0.9.4-1_all.deb
 28c401e1a9502023aa3409ed8847d2bb 1724066 admin optional libvirt-bin_0.9.4-1_i386.deb
 5ae801af14391a46a6786192adf9b7b6 1636362 libs optional libvirt0_0.9.4-1_i386.deb
 2ee5f0409bd93d06557051ce5d0e1dde 4639504 debug extra libvirt0-dbg_0.9.4-1_i386.deb
 e81110c295d20050c160c2fab9a8d229 1956410 libdevel optional libvirt-dev_0.9.4-1_i386.deb
 921e1e136b3da7395e7429dd7a961533 843916 python optional python-libvirt_0.9.4-1_i386.deb
iD8DBQFOQUvYn88szT8+ZCYRAvzsAJ4opUYlaoeRmT0D/G5BVI4OXKFRuwCfcgLj
RXoWIWbfDKJhquH5Uyg4xQs=
=RU7m
-----END PGP SIGNATURE-----

clone 636712 -1
retitle -1 libvirt-bin: please provide README.ifupdown for network integration
severity -1 wishlist
thanks

Hi there!

To which I fully agree, I just do not see the point in having multiple
formats in general (thus not specific to Debian or libvirt): this is the
third I know, after barebone iptables/ifupdown and OpenWrt's UCI [a].

[a] <http://wiki.openwrt.org/doc/uci>

I cloned the bug, please follow-up on the new one given that I am
working on it :-)

The major problem IMHO is to identify both the network interface and the
IP, given that with the default configuration all virtual interfaces
belong to the same bridge.  In case we would also want the MAC address,
`man interfaces` contains the following hint:

	See the get-mac-address.sh script  in the examples directory
	for an  example of such  a mapping script.  See  also Debian
	bug #101728.

Once these information are available, the /e/n/i stanza should be the
following (if I have correctly read `man interfaces`):

  allow-hotplug vnet0
  iface vnet0 inet manual
        post-up /path/to/your/script.sh up
        pre-down /path/to/your/script.sh down

Leave me some more tests and I should come up with a polished and tested
README.ifupdown ;-)

Thx, bye,
Gismo / Luca

notfixed 637219 0.9.4-1
found 637219 0.9.11-2
tags 637219 + patch
thanks

Hi Guido!
thought the problem is not actually the one I described at the beginning
(i.e. add network filters to accept various kind of incoming traffics),
but how to allow port forwarding from the host to the guest.

Reading through the libvirt's resources this is not possible with
network filters and the default NAT virtual network, but one should use
hooks instead:

  <http://wiki.libvirt.org/page/Networking#Forwarding_Incoming_Connections>
  <http://www.libvirt.org/hooks.html>

  <https://www.redhat.com/archives/libvirt-users/2011-April/msg00114.html>
  <https://www.redhat.com/archives/libvir-list/2010-February/msg00243.html>

I can understand why this kind of configurations should not be specified
in the guest XML: simply importing this file into another libvirtd
instance would modify the host's iptables setup, which is wrong.
However, I still fail to understand the full logic behind this: there is
already a way to do such configuration, via the hook script, so why not
integrating this into the nwfilter and letting use libvirt's matching
capabilities (as you suggested)?  Especially because restarting libvirtd
causes the iptables rules for the default NAT virtual network to be
inserted *before* any other rule:

  <https://bugzilla.redhat.com/show_bug.cgi?id=433484>

Never mind, attached a patch against the Git repository.  Please note
that I did not publicize the fact that the hook scripts can be used for
whatever command you would like to execute ;-)

Thx, bye,
Gismo / Luca

Hi there!
[...]

The redirection is wrong, it should simply be ">&2", since only the
stderr will be logged:

  <http://www.libvirt.org/hooks.html#return_codes>

  Return codes and logging

  If a hook script returns with an exit code of 0, the libvirt daemon
  regards this as successful and performs no logging of it.

  However, if a hook script returns with a non zero exit code, the
  libvirt daemon regards this as a failure, logs it with return code
  256, and additionally logs anything on stderr the hook script returns.

Thx, bye,
Gismo / Luca