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