After copiously scouring links all over the place, I think that I've succesfully managed to set up a bridge between my real network interface and the virtual network interface used by virtmanager-hosted virtual machines. I now have F13 hosting a virtualized machine with full network connectivity. Yay.
One glitch remains that I can't fix. After a reboot, /etc/resolv.conf has nothing useful, even though dhclient came up fine on the bridge. Experimentation uncovered NetworkManager as the guilty party.
NetworkManager, AFAIK, doesn't know anything about virtual bridges. I had to set it up by hand:
[root@monster network-scripts]# cat ifcfg-vnet0 DEVICE=vnet0 TYPE=Bridge BOOTPROTO=dhcp ONBOOT=yes
eth0 is bridged:
[root@monster network-scripts]# cat ifcfg-eth0 # Intel Corporation 82573E Gigabit Ethernet Controller (Copper) DEVICE=eth0 BRIDGE=vnet0 #BOOTPROTO=dhcp HWADDR=00:30:48:FC:83:FA ONBOOT=yes OPTIONS=layer2=1 TYPE=Ethernet NM_CONTROLLED=no
[ bunch more stuff snipped ]
I also have eth1, which I would like to be owned by NetworkManager:
[root@monster network-scripts]# cat ifcfg-eth1 # Intel Corporation 82573L Gigabit Ethernet Controller DEVICE=eth1 HWADDR=00:30:48:FC:83:FB ONBOOT=no BOOTPROTO=dhcp TYPE=Ethernet IPV6INIT=no USERCTL=no NM_CONTROLLED=yes PEERDNS=yes
What's happening is this. The S10network script runs first, and brings up eth0 than vnet0; and configures the interface and /etc/resolv.conf from DHCP. Later S23NetworkManager runs, and removes my DNS server from resolv.conf, because none of the NetworkManager-owned network interfaces are up.
I want to use NetworkManager for eth1, but I'll have to either disable it, or bounce the network initscript after NetworkManager, which might cause some confusion elsewhere.
Is there a way to force NetworkManager not to touch /etc/resolv.conf.
On Sun, 2010-09-26 at 12:49 -0400, Sam Varshavchik wrote:
After copiously scouring links all over the place, I think that I've succesfully managed to set up a bridge between my real network interface and the virtual network interface used by virtmanager-hosted virtual machines. I now have F13 hosting a virtualized machine with full network connectivity. Yay.
One glitch remains that I can't fix. After a reboot, /etc/resolv.conf has nothing useful, even though dhclient came up fine on the bridge. Experimentation uncovered NetworkManager as the guilty party.
NetworkManager, AFAIK, doesn't know anything about virtual bridges. I had to set it up by hand:
[root@monster network-scripts]# cat ifcfg-vnet0 DEVICE=vnet0 TYPE=Bridge BOOTPROTO=dhcp ONBOOT=yes
eth0 is bridged:
[root@monster network-scripts]# cat ifcfg-eth0 # Intel Corporation 82573E Gigabit Ethernet Controller (Copper) DEVICE=eth0 BRIDGE=vnet0 #BOOTPROTO=dhcp HWADDR=00:30:48:FC:83:FA ONBOOT=yes OPTIONS=layer2=1 TYPE=Ethernet NM_CONTROLLED=no
[ bunch more stuff snipped ]
I also have eth1, which I would like to be owned by NetworkManager:
[root@monster network-scripts]# cat ifcfg-eth1 # Intel Corporation 82573L Gigabit Ethernet Controller DEVICE=eth1 HWADDR=00:30:48:FC:83:FB ONBOOT=no BOOTPROTO=dhcp TYPE=Ethernet IPV6INIT=no USERCTL=no NM_CONTROLLED=yes PEERDNS=yes
What's happening is this. The S10network script runs first, and brings up eth0 than vnet0; and configures the interface and /etc/resolv.conf from DHCP. Later S23NetworkManager runs, and removes my DNS server from resolv.conf, because none of the NetworkManager-owned network interfaces are up.
I want to use NetworkManager for eth1, but I'll have to either disable it, or bounce the network initscript after NetworkManager, which might cause some confusion elsewhere.
Is there a way to force NetworkManager not to touch /etc/resolv.conf.
---- PEERDNS=no
Craig
On Sun, 26 Sep 2010 09:56:34 -0700 Craig White wrote:
PEERDNS=no
Which you have to put in each ifcfg-* script managed by NetworkManager.
Or if you are lazy you can always use the giant hammer:
chattr +i /etc/resolv.conf
(which I've had to do on some linux distros that grant the resolve.conf update algorithms the protection of the Obfuscation Gods :-).
On Sun, 2010-09-26 at 16:27 -0400, Tom Horsley wrote:
On Sun, 26 Sep 2010 09:56:34 -0700 Craig White wrote:
PEERDNS=no
Which you have to put in each ifcfg-* script managed by NetworkManager.
Or if you are lazy you can always use the giant hammer:
chattr +i /etc/resolv.conf
(which I've had to do on some linux distros that grant the resolve.conf update algorithms the protection of the Obfuscation Gods :-).
---- I would probably classify that as pathologically stupid system administration considering the relative ease you can change even a lot of ifcfg-* scripts with a simple sed command but the great thing about UNIX/Linux is that the superuser is entitled to admin his own box - even with really bad conceptual practices.
Craig
On Sun, 26 Sep 2010 15:11:48 -0700 Craig White wrote:
I would probably classify that as pathologically stupid system administration considering the relative ease you can change even a lot of ifcfg-* scripts with a simple sed command but the great thing about UNIX/Linux is that the superuser is entitled to admin his own box - even with really bad conceptual practices.
Some releases of ubuntu have been exceptionally stubborn. They don't use ifcfg-* scripts, and the docs available on the release didn't match the actual behavior of the system, so as opposed to spending several days of research, chattr was much simpler :-).
Opensuse is also totally different, not using PEERDNS, but at least opensuse provides an actual comment in the generated /etc/resolve.conf file telling you how to modify the default (which is good, because they can't make up their mind how it should work, and they seem to change it in every single opensuse release).
I do wish providing comments in automagically generated config files like resolve.conf and others was a blocker for releases. If the generated file doesn't have an accurate comment describing how to modify the way it was generated, you shouldn't be able to inflict the release on the world, but right now opensuse seems to be the only distro I've seen that provides the comment.
On Sun, Sep 26, 2010 at 7:54 PM, Tom Horsley horsley1953@gmail.com wrote:
Some releases of ubuntu have been exceptionally stubborn. They don't use ifcfg-* scripts, and the docs available on the release didn't match the actual behavior of the system, so as opposed to spending several days of research, chattr was much simpler :-).
In Ubuntu, if you use NM, you have to set the DNS servers through the NM applet. There's probably an NM xml file that can be edited if you want to use the CLI - somewhere.
I do wish providing comments in automagically generated config files like resolve.conf and others was a blocker for releases. If the generated file doesn't have an accurate comment describing how to modify the way it was generated, you shouldn't be able to inflict the release on the world, but right now opensuse seems to be the only distro I've seen that provides the comment.
+1
Tom Horsley horsley1953@gmail.com writes:
On Sun, 26 Sep 2010 09:56:34 -0700 Craig White wrote:
PEERDNS=no
Which you have to put in each ifcfg-* script managed by NetworkManager.
Or just put it in /etc/sysconfig/network and hit them all at once.
There are a bunch of other nice things you might want to put in there while you are at it:
/etc/sysconfig/network: NETWORKING=yes HOSTNAME=xxx.example.com DHCP_HOSTNAME=$HOSTNAME IPV6_ROUTER=yes IPV6FORWARDING=yes PEERDNS=no # /etc/resolv.conf PEERNTP=no # /etc/ntp.conf, /etc/ntp/step-tickers PEERNIS=no # /etc/yp.conf NETWORKWAIT=yes
-wolfgang
Wolfgang S. Rupprecht writes:
Tom Horsley horsley1953@gmail.com writes:
On Sun, 26 Sep 2010 09:56:34 -0700 Craig White wrote:
PEERDNS=no
Which you have to put in each ifcfg-* script managed by NetworkManager.
Or just put it in /etc/sysconfig/network and hit them all at once.
There are a bunch of other nice things you might want to put in there while you are at it:
/etc/sysconfig/network: NETWORKING=yes HOSTNAME=xxx.example.com DHCP_HOSTNAME=$HOSTNAME IPV6_ROUTER=yes IPV6FORWARDING=yes PEERDNS=no # /etc/resolv.conf PEERNTP=no # /etc/ntp.conf, /etc/ntp/step-tickers PEERNIS=no # /etc/yp.conf NETWORKWAIT=yes
The follow-up question is whether there are any plans for NetworkManager to understand and handle network bridge devices. That's why I had to fight with NetworkManager in the first place.
If NetworkManager grokked bridges, a lot of other things would fall into place. I could set up a bridge, then attach the bridge to a virtual host without having to do anything from a shell. Everything would've been handled in NetworkManager's and virt-manager's gui.
-
Craig White -
Sam Varshavchik -
Tom H -
Tom Horsley -
Wolfgang S. Rupprecht