Le 03/28/2013 16:59, Laine Stump wrote :
On 03/25/2013 05:12 PM, Benoit Friry wrote:
On 03/25/2013 16:21, Eric Blake wrote:
On 03/25/2013 03:09 AM, Benoit Friry wrote:
- starting default network (nat) adds rules in netfilter. I have not seen how to create another network nat conf without calling clean-traffic nwfilter (it is not explicit in network XML file).
nwfilter rules are applied to individual *guest interfaces* by adding a <filterref> element to the guest's <interface> element. They are completely unrelated to the netfilter rules added when a libvirt network is started.
Indeed, I thought the added rules where from nwfilter. I did not checked precisely. I did not suspect there were another set of rules for networks.
The rules added for a libvirt virtual network change depending on the setting of "<forward mode='xxx'>" in the network config
1) for <forward mode='route'> a set of rules allowing all traffic in both directions is added
2) for <forward mode='nat'> rules are added to allow outbound traffic from the guests to any destination, prevent inbound traffic from anywhere except a) the host and b) other guests attached to the same network, AND to mangle the source address of packets outbound to places beyond the host (so that they appear to be coming from the host itself).
3) if there is *no* <forward> (aka an "isolated" network), rules are added to allow traffic only between guests on the same network and the host, but block all other traffic.
The rules for each of these cases is hardcoded (and also very simplistic) and can't be configured in any more finely grained manner.
It's a pity. There is nothing between all hardcoded rules and all manual rules (in mode='bridge'). Manual rules are to be managed outside. It would have been nice to be able to start/stop specific rules from libvirt, linked to network start/stop commands. Thanks for the explanation.
- to be able to change the templates, for instance: - not including any nwfilter when creating a network, - script called when adding a file in a dir pool, - and so on. Another example: what if I want to use BIND9 instead of dnsmasq? BIND9 has a dns64 capability, dnsmasq has not.
dnsmasq, radvd, brctl are hardcoded. Don't you think it would be better to call a helper script, that can be tweaked by admins?
No. That would be a nightmare to support; we specifically avoid doing something that free-form. If you would like a network driver that uses different utilities in place of dnsmasq and radvd, the proper way to do that is with a different network driver to be built in place of src/network/bridge_driver.c.
Ouch. Isn't it overkill? I can manage some scripts. I will not manage patches, to be rebuild with every new release. Few organization can afford such thing! What about a overwrite conf file? Hardcoded conf by default, but one can change some element. Support only when no overwrited conf.
But before you go to that trouble, are you certain that dnsmasq still doesn't have what you need? Recent versions of libvirt (since 1.0.1) have support for many new IPv6 features of dnsmasq 2.66+, including DHCP6, and I think dnsmasq has had support for IPv6 DNS resolution for quite a long time. (I couldn't figure out from a quick google search whether or not dnsmasq directly supports DNS64, or if that may be unnecessary if the dns server upstream from dnsmasq has DNS64 support.)
AFAIK, dnsmasq has no DNS64 support. Thanks, Benoit