1:46 p.m.
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...)
3:40 p.m.
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
7:26 p.m.
On 10/01/2010 04:40 PM, Eric Blake wrote:
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).
The problem may be that not everyone knows how to enable forwarding,
filtering, or reads log files. People are used to that networking (or
filtering) works out-of-the box but then on one installation for some
reason it doesn't. After some time typically one finds the answer online
somewhere what needs to be configured... I guess documentation is 'key'.
Maybe libvirt could have an admin mode 'somehow' that prevents it from
automatically making those changes whereas the less-savvy audience gets
it set up all automatically.
Stefan
3:44 p.m.
Uh huh, hi?
On 10/01/2010 08:46 PM, Laine Stump wrote:
[...]
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".
You've got me a bit confused here, because what exactly is supposed #
sysctl -a -p; do? I mean, what kind of magic?
I've tried this and if I turn on net.ipv4.ip_forward to '1' and run #
sysctl -a -p; it stays on, unless defined as 0 in /etc/sysctl.conf (and
sysctl run only with -p, not -a AND -p). And if it's defined as 0 there,
then there must be reason for being so. Also, why on Earth would you
have every sysctl parameter in /etc/sysctl.conf unless you're not happy
with default ones? Imho this file is for fine tuning, thus ~ include
things what I don't like or want changed, but not every possible kernel
option which I might or might not want to change. Because then there is
no surprise for such odd behavior.
Also, the outlined problem here sounds more like "left hand doesn't know
what's doing right hand" or I just didn't get your point. I'm also
missing the previous discussion about the problem, if there was any. I
mean, your e-mail comes out of the blue sky without any previous reference.
I hope this doesn't sound too much jerk-ish, but I kinda don't like too
much what I'm reading here.
Have a nice weekend and thank you for your (or anyone's) reply on this one.
Zdenek
--
Zdenek Styblik
Net/Linux admin
OS TurnovFree.net
email: stybla(a)turnovfree.net
jabber: stybla(a)jabber.turnovfree.net
1:13 p.m.
On 10/01/2010 04:44 PM, Zdenek Styblik wrote:
Uh huh, hi?
On 10/01/2010 08:46 PM, Laine Stump wrote:
[...]
> 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".
>
You've got me a bit confused here, because what exactly is supposed #
sysctl -a -p; do? I mean, what kind of magic?
Sorry about that - remove the "-a" from that command.
No magic. As the manpage says, "sysctl -p" reads the provided file (or
/etc/sysctl.conf if no file is provided) and sets all the kernel
parameters listed there to the values given. As you know,
/etc/sysctl.conf is used, at least on RHEL and Fedora, to "permanently"
set kernel parameter values to something other than the defaults
hardcoded into the kernel and loadable kernel modules. (actually they
can be modified to something else either by individually setting them
with sysctl -w or by writing directly to the /proc entry, but this will
be overridden the next time "sysctl -p" is run).
On both RHEL and Fedora, both the network and NetworkManager services
(and others, eg see the bug reports a bit further down in this reply)
run sysctl with -p to reload all non-kernel-default settings when they
are started, and Fedora puts "net.ipv4.ip_forward=0" into
/etc/sysctl.conf at install time. So at boot time, both of those
services run "sysctl -p" which sets ip_forward to 0, then libvirtd
starts, which sets it to 1. At this point, libvirt virtual networks are
running (as expected), but also there may be some other unwanted routing
going on (which the admin won't expect). If the network or
NetworkManager service is later manually restarted (or some other
parameter is added to sysctl.conf and it's reloaded with "sysctl -p" as
many HOWTO documents suggest when changing a kernel parameter),
libvirt's virtual networks suddenly/unexpectedly stop working.
I've tried this and if I turn on net.ipv4.ip_forward to
'1' and run #
sysctl -a -p; it stays on, unless defined as 0 in /etc/sysctl.conf (and
sysctl run only with -p, not -a AND -p).
Right, my mistake.
And if it's defined as 0 there,
then there must be reason for being so.
Exactly one of my points. libvirt really wants (no, *needs*) this to be
on for virtual networks, but it's very likely there was a reason for it
being turned off, so the admin should at the very least be alerted that
it's being turned on, or the fact that it's off should be logged in some
way to assure it gets the admin's attention so they can make the proper
judgement call.
Also, why on Earth would you
have every sysctl parameter in /etc/sysctl.conf unless you're not happy
with default ones?
Nobody is talking about putting any value there other than
net.ipv4.ip_forward (which, on RHEL and Fedora is already put there by
the installer), and that only to assure that it's set to the value that
libvirtd needs for its virtual networks to work properly. (Possibly my
erroneous addition of "-a" threw you off there).
Imho this file is for fine tuning, thus ~ include
things what I don't like or want changed, but not every possible kernel
option which I might or might not want to change. Because then there is
no surprise for such odd behavior.
Also, the outlined problem here sounds more like "left hand doesn't know
what's doing right hand" or I just didn't get your point.
Again you are correct. currently libvirt is turning it on without
documenting that fact in the (as far as I know) standard accepted place
of doing so - /etc/sysctl.conf.
I'm also
missing the previous discussion about the problem, if there was any. I
mean, your e-mail comes out of the blue sky without any previous reference.
Two Active bug reports that I'm aware of offhand (one for RHEL and one
for Fedora):
https://bugzilla.redhat.com/show_bug.cgi?id=612865
https://bugzilla.redhat.com/show_bug.cgi?id=612867
There are also related bugs for older Fedora releases:
https://bugzilla.redhat.com/show_bug.cgi?id=240922
https://bugzilla.redhat.com/show_bug.cgi?id=426792
https://bugzilla.redhat.com/show_bug.cgi?id=467687
https://bugzilla.redhat.com/show_bug.cgi?id=514228
The first two prompted a short discussion on an internal Red Hat call,
first a brief mention of it a month or two ago, and again in a similar
call last week, where the main point of the conversation was "1) this is
a problem, 2) we should fix it, 3) here's a list of some ideas, 4) we
need to post these ideas on libvir-list to start a conversation in the
libvirt community about the best course of action."
I'm not sure how else we could have proceeded that would have made it
less of a surprise to you. (Of course now that I've hopefully better
articulated myself, you may be less surprised :-)
I hope this doesn't sound too much jerk-ish, but I kinda
don't like too
much what I'm reading here.
You may be reading more into this than is there - the discussion is
newly started, no code has even been written yet (much less patches
posted, or pushed), and none of the proposed changes are as sweeping as
you may think.
It sounds like we agree on at least a couple of important points: 1)
"the left hand should know what the right hand is doing" and 2) if
ip_forward is set to 0, that was likely done for a reason, so we
shouldn't silently modify it. it. Beyond that, is a point that is really
just a fact, not an opinion: 3) libvirt's virtual networks won't work
unless ip_forward is turned on. The current code is only compatible with
1 of those 3; we need to agree on a method to satisfy all of them. Are
you voting for my proposal (1) in the original mail? (do nothing), or do
you have another idea?
6:48 a.m.
On 10/04/2010 08:13 PM, Laine Stump wrote:
[...]
[...more of sysctl.conf...]
>> [...]
> Two Active bug reports that I'm aware of offhand (one for RHEL and one
> for Fedora):
[...]
> The first two prompted a short discussion on an internal Red Hat call,
> first a brief mention of it a month or two ago, and again in a similar
> call last week, where the main point of the conversation was "1) this is
> a problem, 2) we should fix it, 3) here's a list of some ideas, 4) we
> need to post these ideas on libvir-list to start a conversation in the
> libvirt community about the best course of action."
> I'm not sure how else we could have proceeded that
would have made it
> less of a surprise to you. (Of course now that I've hopefully better
> articulated myself, you may be less surprised :-)
Reference to these(or anything else) would help. ;)
> You may be reading more into this than is there - the
discussion is
> newly started, no code has even been written yet (much less patches
> posted, or pushed), and none of the proposed changes are as sweeping as
> you may think.
Well, I haven't thought about such possibility in the first place.
> It sounds like we agree on at least a couple of important points: 1)
> "the left hand should know what the right hand is doing" and 2) if
> ip_forward is set to 0, that was likely done for a reason, so we
> shouldn't silently modify it. it. Beyond that, is a point that is really
> just a fact, not an opinion: 3) libvirt's virtual networks won't work
> unless ip_forward is turned on. The current code is only compatible with
> 1 of those 3; we need to agree on a method to satisfy all of them. Are
> you voting for my proposal (1) in the original mail? (do nothing), or do
> you have another idea?
To get back to original points/summary:
> I think the important things to accomplish are:
> 1) Avoid having networking magically stop working when
someone else
> reloads sysctl.conf
I think this can't be guaranteed unless periodical polling. I mean, it
doesn't(well "doesn't") matter if you modify /etc/sysctl.conf or
'echo
1' into /proc/...; it still can be turned off.
More, the point is network can magically stop working whenever I or
anybody please. This is not only about /etc/sysctl.conf, I'm afraid.
Right, the question is what's better (the best) approach here.
echo 1 into /proc/... only when it's needed and note in documentation
about this?
> 2) Make sure that the admin realizes that ip_forward is being turned on
> (or needs to be turned on).
Documentation?
> 3) If we're going to turn it on, at least don't do it if it's not
needed.
I agree.
> (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...)
Once again I'm going to "troll" about this and bundled everything inside
one thing. As I've said many times already, I'm pro-external things as
DHCP, firewall ... whatever. On the other hand, I realize the point of
libvirt might be to ship out-of-the-box solution like it is now.
I mean, tell admin what to add if he wants this and that; or make
external hooks, or whatever. That's hard to say, because there is no one
ultimate solution.
I hope this makes some sense,
Zdenek
--
Zdenek Styblik
Net/Linux admin
OS TurnovFree.net
email: stybla(a)turnovfree.net
jabber: stybla(a)jabber.turnovfree.net
On 10/01/2010 04:44 PM, Zdenek Styblik wrote:
[...sysclt
stuff...]
On both RHEL and Fedora, both the network and NetworkManager services
(and others, eg see the bug reports a bit further down in this reply)
Hm, how to put it. I, for myself, don't like idea of fixing something
just because of other buggy applications. But this expression might be
wrong - it is probably wrong expression indeed.
run sysctl with -p to reload all non-kernel-default settings when
they
are started, and Fedora puts "net.ipv4.ip_forward=0" into
/etc/sysctl.conf at install time. So at boot time, both of those
Yes, well you can change that, although this would turn on IP forward by
default.
Exactly one of my points. libvirt really wants (no, *needs*) this to
be
on for virtual networks, but it's very likely there was a reason for it
being turned off, so the admin should at the very least be alerted that
it's being turned on, or the fact that it's off should be logged in some
way to assure it gets the admin's attention so they can make the proper
judgement call.
Only thing that popped in my head was: admin should read documentation :(
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).
I don't fully understand it, thus - I don't know :)
6:57 a.m.
On 10/07/2010 10:48 PM, Zdenek Styblik wrote:
On 10/04/2010 08:13 PM, Laine Stump wrote:
<snip>
> Exactly one of my points. libvirt really wants (no, *needs*) this
to be
> on for virtual networks, but it's very likely there was a reason for it
> being turned off, so the admin should at the very least be alerted that
> it's being turned on, or the fact that it's off should be logged in some
> way to assure it gets the admin's attention so they can make the proper
> judgement call.
>
Only thing that popped in my head was: admin should read documentation :(
Is this the kind of behavioural thing that we should have a "reasonable
default" for, plus allow for it to be configured differently via
libvirtd.conf?
were_special_really_really_really_please_dont_enable_ipforwarding = 1
:)
Once again I'm going to "troll" about this and bundled
everything inside
one thing. As I've said many times already, I'm pro-external things as
DHCP, firewall ... whatever. On the other hand, I realize the point of
libvirt might be to ship out-of-the-box solution like it is now.
I mean, tell admin what to add if he wants this and that; or make
external hooks, or whatever. That's hard to say, because there is no one
ultimate solution.
Using the words "hooks" here makes me wonder if we could do the needed
work through having network hook scripts in place (with appropriate bits
to call them), and whether it would be a useful way of doing things.
(absolutely no idea if it's even feasible. :>)
8:03 a.m.
On 10/07/2010 01:57 PM, Justin Clift wrote:
On 10/07/2010 10:48 PM, Zdenek Styblik wrote:
> On 10/04/2010 08:13 PM, Laine Stump wrote:
<snip>
>> Exactly one of my points. libvirt really wants (no, *needs*) this to be
>> on for virtual networks, but it's very likely there was a reason for it
>> being turned off, so the admin should at the very least be alerted that
>> it's being turned on, or the fact that it's off should be logged in some
>> way to assure it gets the admin's attention so they can make the proper
>> judgement call.
>>
>
> Only thing that popped in my head was: admin should read documentation :(
Is this the kind of behavioural thing that we should have a "reasonable
default" for, plus allow for it to be configured differently via
libvirtd.conf?
were_special_really_really_really_please_dont_enable_ipforwarding = 1
:)
Umm I don't know, but this feels as being somewhat out of the context.
Ok, I don't think more log bogus will solve anything. Admin should know
what software does; software documentation should clearly state what
software does and does not.
I really don't know what else to say about proposed point :)
> Once again I'm going to "troll" about this and bundled everything
inside
> one thing. As I've said many times already, I'm pro-external things as
> DHCP, firewall ... whatever. On the other hand, I realize the point of
> libvirt might be to ship out-of-the-box solution like it is now.
> I mean, tell admin what to add if he wants this and that; or make
> external hooks, or whatever. That's hard to say, because there is no one
> ultimate solution.
Using the words "hooks" here makes me wonder if we could do the needed
work through having network hook scripts in place (with appropriate bits
to call them), and whether it would be a useful way of doing things.
(absolutely no idea if it's even feasible. :>)
Well, it might not be terminus technicus. I also see that I have
unfinished point here.
What I meant was and is that eg. DCC has in documentation what rules you
have/should add into your firewall to make DCC to work.
Hooks as external shell or whatever scripts - truly, I don't know,
although that was point of some sort.
Zdenek
--
Zdenek Styblik
Net/Linux admin
OS TurnovFree.net
email: stybla(a)turnovfree.net
jabber: stybla(a)jabber.turnovfree.net
7:14 a.m.
On Fri, Oct 01, 2010 at 02:46:34PM -0400, Laine Stump wrote:
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.
We have to bear in mind that this functionality has existed in
libvirt for 4 years now and as such we really don't want to cause
a regression in behaviour for people. Option 1 does have the
problem you mention, but for the vast majority of people it has
been working for years & they'll be annoyed if we break it.
To me, this ties back in with the problem of managing the firewall
in general. Toggling of ip forward should be something done by the
firewall management service....of which none exists yet. There is
current active development work to provide a dynamic firewall
management service in Fedora. This is to address the needs of libvirt,
NetworkManager, CUPs, System-D all of whom are suffering from the
current lack of firewall management. I expect the ip_forward setting
will fall under this service.
My preference would thus be to leave current libvirt behaviour
unchanged and wait to see how the firewall mgmt work plays out
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.
This would be a major regression for anyone upgrading their libvirt
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.
Agreed, this is the wrong time/place.
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.
Yeah, doesn't make much sense to have to edit a config file to
change a variable in a different config file. It is no better
than telling people to edit sysctl.conf.
Daniel
--
|: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://deltacloud.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
9:28 a.m.
I'd forgotten to reply to this before...
On 10/07/2010 08:14 AM, Daniel P. Berrange wrote:
On Fri, Oct 01, 2010 at 02:46:34PM -0400, Laine Stump wrote:
> 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.
We have to bear in mind that this functionality has existed in
libvirt for 4 years now and as such we really don't want to cause
a regression in behaviour for people. Option 1 does have the
problem you mention, but for the vast majority of people it has
been working for years& they'll be annoyed if we break it.
To me, this ties back in with the problem of managing the firewall
in general. Toggling of ip forward should be something done by the
firewall management service....of which none exists yet. There is
current active development work to provide a dynamic firewall
management service in Fedora. This is to address the needs of libvirt,
NetworkManager, CUPs, System-D all of whom are suffering from the
current lack of firewall management. I expect the ip_forward setting
will fall under this service.
My preference would thus be to leave current libvirt behaviour
unchanged and wait to see how the firewall mgmt work plays out
If there is some other/better solution brewing, then I'm happy to wait
to see how it works out. The current situation, although it's been this
way for a long time, is just asking for trouble, however.
I'm going to look into the firewall management project and see if I can
help by trying out integrating it into libvirt.
5151
days inactive
5168
days old
9 comments
6 participants
participants (6)
-
Daniel P. Berrange -
Eric Blake -
Justin Clift -
Laine Stump -
Stefan Berger -
Zdenek Styblik