[libvirt-users] Host modifications

[Benoit Friry]

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