[Date Prev][Date Next] [Thread Prev][Thread Next]
Re: [libvirt] RFC: automatic setting of ip_forwarding (or not)
- From: Zdenek Styblik <stybla turnovfree net>
- To: Laine Stump <laine laine org>
- Cc: Libvirt <libvir-list redhat com>
- Subject: Re: [libvirt] RFC: automatic setting of ip_forwarding (or not)
- Date: Thu, 07 Oct 2010 13:48:06 +0200
On 10/04/2010 08:13 PM, Laine Stump wrote:
> On 10/01/2010 04:44 PM, Zdenek Styblik wrote:
> 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
> 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 :(
[...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
> 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
> 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 :)
> (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
I hope this makes some sense,
email: stybla turnovfree net
jabber: stybla jabber turnovfree net
[Date Prev][Date Next] [Thread Prev][Thread Next]