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

[Eric Blake]

On 10/01/2010 12:46 PM, Laine Stump wrote:
> 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.

Option 3 is consistent with what we just checked in for nwfilter vs. 
/proc/sys/net/bridge/bridge-nf-call-ip[6]tables in commit 570d040435.

On the surface, I'm liking that option best - tell the user that we 
can't do what they asked because it requires them to make a conscious 
admin decision; even though it unfortunately doesn't play nicely with 
out-of-the-box installation (and that matters more for user attitudes 
than anything else, in my experience).


> 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.


Now, thinking a bit outside the box: is it possible to create a 
libvirt-network package, whose sole purpose is to turn on the ip_forward 
setting at install time?  That is, the main libvirt package doesn't 
touch the setting, but an optional add-on package does; that way, users 
can choose whether to install one or both packages, depending on their 
intended usage patterns.  In other words, I think point 4 via split 
packaging solves this nicely.


> I think the important things to accomplish are:

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

Agreed.  Point 3 meets this, but by putting the burden on the sysadmin. 
  Point 4 also meets it by actually changing the persistent config, if 
the optional package is installed.

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

Point 3 meets this via error message; point 4 meets this by explicitly 
requesting the extra package.

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

Point 3 meets this by leaving it up to the sysadmin; point 4 meets this 
by leaving the optional package out.

>
> 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).

Not sure how best to address this through just libvirt API.

-- 
Eric Blake   eblake at redhat.com    +1-801-349-2682
Libvirt virtualization library http://libvirt.org