[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

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

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 redhat com    +1-801-349-2682
Libvirt virtualization library http://libvirt.org

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]