[libvirt] RFC: automatic setting of ip_forwarding (or not)

[Laine Stump]

  Currently libvirt will turn on net.ipv4.ip_forward by writing "1\n" to 
/proc/sys/net/ipv4/ip_forward whenever a virtual network of with a 
forward mode of "nat" or "route" is started. This is problematic for two 
reasons: 1) /etc/sysctl.conf is not updated with this information, so 
any other process reprocessing /etc/sysctl.conf (with "sysctl -a -p") 
will potentially turn ip forward back to 0, leaving libvirt-created 
virtual networks in a non-working state, and 2) it's possible the 
administrator turned off ip forwarding on purpose for security reasons, 
and our silently turning it on leaves them mistakenly believing it is 
still off.

We've discussed a few ways of remedying this situation lately, and I 
thought I should summarize all the mentioned ideas, and take a poll to 
try and determine which way we should fix this.

1) Leave it as is. The simplest solution, but has the problems outlines 
above.

2) Turn it on in the same place, but do it by writing

      net.ipv4.ip_forward = 1

to /etc/sysctl.conf and calling "sysctl -a -p". This gives us the same 
behavior as currently, but with the advantages that a) our change to the 
config is documented in /etc/sysctl.conf and b) virtual networked guests 
won't suddenly have their network fail when some other process runs 
"sysconfig -a -p".

However, it seems rather drastic to be turning this on every time a 
virtual network is started, especially without alerting the admin that 
this has been done.

3) Whenever a virtual network that would require ip_forward = 1 to 
operate properly is started (ie at libvirtd start time, and when a 
network is newly defined), check if it's currently on, and if not log a 
warning message, informing the admin that they should turn on ip_forward 
in sysctl.conf and reload it in order to have properly working networking.

This would assure that the admin was informed of the necessity for 
ip_forward, but eliminate the possibility of two processes fighting over 
the setting of ip_forward, leaving it up to the admin to make the 
decision and do the right thing. On the other hand, it would prevent 
libvirt's networking from "just working" on a new install.

4) Turn ip_forward on during libvirt install.

This one doesn't make sense to me, because you don't know at the time of 
libvirt install whether or not the installation if going to end up with 
any virtual networks that need forwarding.

5) Make ip_forward a tunable in /etc/libvirt/libvirtd.conf, and set it 
accordingly every time libvirtd is started.

I don't know if this makes sense either - if you have NATed or routed 
virtual networks, you will need ip_forward=1 for them to work properly, 
and if you don't have them, you don't care, so it's really redundant.


****

I think the important things to accomplish are:

1) Avoid having networking magically stop working when someone else 
reloads sysctl.conf

2) Make sure that the admin realizes that ip_forward is being turned on 
(or needs to be turned on).

3) If we're going to turn it on, at least don't do it if it's not needed.

4) Something else we need to consider is the ability to provision a host 
for proper guest networking purely through the libvirt API, and if we 
were to stop turning on ip_forward automatically when a network was 
started, that wouldn't work anymore (unless ip_forward happened to be 
turned on already).


So, what are your opinions?


(BTW, the firewall rules added for virtual networks suffer from a 
similar problem - because they're loaded into the kernel directly with 
the iptables command, there is no external record of them, and some 
other process reloading the firewall will flush out all libvirt's rules, 
leaving the guests with nonworking networking. But that discussion is a 
bigger one, that probably needs to go outside just libvirt, so I'll 
avoid that here...)