Bug 467687 - Virtual network won't work until restart
Virtual network won't work until restart
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: libvirt (Show other bugs)
10
All Linux
medium Severity medium
: ---
: ---
Assigned To: Daniel Veillard
Fedora Extras Quality Assurance
:
: 463298 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-10-20 05:24 EDT by Julian Sikorski
Modified: 2009-02-25 05:21 EST (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-02-24 13:26:58 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
Output of requested commands before restart (6.80 KB, text/plain)
2009-01-21 04:46 EST, Julian Sikorski
no flags Details
Output of requested commands after restart (6.83 KB, text/plain)
2009-01-21 04:46 EST, Julian Sikorski
no flags Details
Differences between the two (7.74 KB, patch)
2009-01-21 04:47 EST, Julian Sikorski
no flags Details | Diff

  None (edit)
Description Julian Sikorski 2008-10-20 05:24:29 EDT
Description of problem:
I have a fullvirt i386 rawhide running inside a Fedora 9 x86_64 host. The problem is that the guest's network will not work until I go to virt-manager, qemu, details, virtual networks and then restart it by hitting stop followed by run. It is interesting that the guest seems to be able to resolve names, looks like it just cannot connect to anything.

Version-Release number of selected component (if applicable):
libvirt-0.4.6-2.fc9.x86_64
virt-manager-0.5.4-4.fc9.x86_64

How reproducible:
always

Steps to Reproduce:
1. Install a fully virtualised rawhide guest
2. Run it
3. Attempt to access network from within a guest
  
Actual results:
Network is not working.

Expected results:
Network is working without the need for restart.

Additional info:
Please let me know what additional useful data I could provide.
Comment 1 Julian Sikorski 2008-12-12 10:43:29 EST
This is still the case with Fedora 10 and libvirt-0.5.0-1.fc10.x86_64.
Comment 2 Mark McLoughlin 2009-01-21 04:29:08 EST
Julian: do you have any special iptables scripts or configuration?

Try running these commands before and after the restart and attach the output here:

  $> brctl show
  $> iptables -L -v -n
  $> ps -ef | grep dnsmasq
  $> ifconfig -a
  $> cat /proc/sys/net/ipv4/ip_forward
Comment 3 Julian Sikorski 2009-01-21 04:46:23 EST
Created attachment 329572 [details]
Output of requested commands before restart

Nothing that I'm aware of.
Comment 4 Julian Sikorski 2009-01-21 04:46:58 EST
Created attachment 329573 [details]
Output of requested commands after restart
Comment 5 Julian Sikorski 2009-01-21 04:47:55 EST
Created attachment 329574 [details]
Differences between the two
Comment 6 Mark McLoughlin 2009-01-21 05:19:21 EST
There's the problem:

  [root@snowball jsikorski]# cat /proc/sys/net/ipv4/ip_forward
  -0
  +1

See also bug #240922

Could try and figure out what's loading /etc/sysctl.conf at boot after libvirtd is started ?

danpb's theory was that it's NetworkManager, but on F10 with NetworkManager after boot I see:

  $> grep ip_forward /etc/sysctl.conf 
  net.ipv4.ip_forward = 0
  $> cat /proc/sys/net/ipv4/ip_forward 
  1
Comment 7 Daniel Berrange 2009-01-21 05:27:29 EST
On my F10 hosts I see 2 init scripts which either load all sysctl.conf settings, or explicitly set ip_forward - the 'network' script or the 'NetworkManager' script

network:        sysctl -e -p /etc/sysctl.conf >/dev/null 2>&1
network:        sysctl -e -p /etc/sysctl.conf >/dev/null 2>&1
network:                        action $"Disabling IPv4 packet forwarding: " sysctl -w net.ipv4.ip_forward=0
network:                        action $"Disabling IPv4 automatic defragmentation: " sysctl -w net.ipv4.ip_always_defrag=0
NetworkManager: sysctl -e -p /etc/sysctl.conf >/dev/null 2>&1

The priority of both of these initscripts means that libvirtd should always be started after they are run.

A non-initscript possibility could be that NetworkManager C code has something which sets ip_forward upon connecting to a wifi network ?  This could conceivably happen after libvirtd has started, thus breaking connectivity ?
Comment 8 Julian Sikorski 2009-01-21 05:38:06 EST
It's possible since I'm using wifi here. Will check that later today.
Comment 9 Julian Sikorski 2009-01-21 07:15:15 EST
ip_forward is set to 0 at the time gdm starts, before logging in to the desktop (checked on tty2). But, if the messages appearing during boot-up are right, NM starts after libvirtd, so that should probably explain everything.
Comment 10 Mark McLoughlin 2009-02-02 12:58:46 EST
*** Bug 463298 has been marked as a duplicate of this bug. ***
Comment 11 Julian Sikorski 2009-02-24 12:49:42 EST
The priority is clearly wrong here. How can I assure libvirt gets started after NM?
Comment 12 Julian Sikorski 2009-02-24 13:26:58 EST
OK, got it. I had old priorities lying around.
Comment 13 Mark McLoughlin 2009-02-25 04:41:38 EST
(In reply to comment #12)
> I had old priorities lying around.

Julian: could you provide a little more info as to what the problem was?

e.g. did you have the priority overridden in /etc/chkconfig.d, or had you manually modified the initscripts, or had you manually changed runlevel symlinks?

I've added some info to:

  https://fedoraproject.org/wiki/Reporting_virtualization_bugs#Networking

Please make sure that would have helped you resolve the issue. Thanks.
Comment 14 Julian Sikorski 2009-02-25 05:21:44 EST
I had old runlevel symlinks lying around, probably from the times when NM wasn't yet moved up in the boot process (S99NetworkManager). It seems that the priorities are not reset during upgrades.
Looking at the wiki page, indeed the
#chkconfig NetworkManager resetpriorities
command was what solved the problem. I *think* I had to reset haldaemon as well so that it starts before NM. Hope that helps.

Note You need to log in before you can comment on or make changes to this bug.