Bug 1100034
Summary: | Network route disappearing after suspend | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Aleksandar Kostadinov <akostadi> |
Component: | NetworkManager | Assignee: | Lubomir Rintel <lkundrak> |
Status: | CLOSED CURRENTRELEASE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | unspecified | Docs Contact: | |
Priority: | unspecified | ||
Version: | 21 | CC: | akostadi, berrange, clalancette, crobinso, dcbw, ehabkost, extras-orphan, gansalmon, itamar, jen, jonathan, kernel-maint, madhu.chinakonda, markmc, mchehab, micha, nhorman, psimerda, quintela, virt-maint |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2015-10-19 15:17:34 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Aleksandar Kostadinov
2014-05-21 20:34:36 UTC
I see actually that systemctl restart network does not work on my host machine also. Not only in the guest. FYI I'm getting the issue after suspend now more consistently than before. Perhaps package upgrades have changed that. Any idea if this issue is to be fixed? To me not having "systemctl restart network" working is a pretty fundamental issue and deserved more attention. Not sure if/how it is related to the issues I see after suspend. bump, any idea how to debug this losing default route on the VM after host suspend? Also sometimes machine hangs with spiky CPU usage as shown by virt-manager. I'm really not sure what to look for here... kernel guys, any ideas for additional debugging? How do you specify the default route in your configuration? Do you hard code it in a config file (or network manager)? Or do you find the default route from your DHCP offer? If you do the latter, my guess is that on suspend, network manager actually takes down your interface, erasing the default gateway via that device, and never restores it. You can work around I imagine by adding a default gateway route in the networkmanager connections dialog, but the actual problem is likely to be fixed in NM Neil, I'm using the default NAT network created by virt-manager. I never configured anything network by hand. To restore default route I found that `systemctl restart NetworkManager` helps. It's also interesting that IP/mask remains the same but only default route is lost. This doesn't explain though why sometimes the VM is hung with high spiky CPU usage. Might be unrelated. Aleksandar, as you still seeing this with up to date f20 host and VM? Yes, I just tried updating and default route is still lost. Aleksandar, yes, that means you're using the default gateway provided in your DHCP offer, as I explained in comment 5. That suggests that NetworkManager is where this needs to be fixed. Until then, you can likely work around the problem by adding the default route in the NM connection dialog, so that NM knows to restore it on resume So why NetworkManager on host is able to restore network when host is suspended but running on guest, it's unable to restore network? IMO there's some issue in the suspend/wake-up sequence. Maybe virtual network not up at the time NM does what it does or DHCP server doing something strange. In any case, I hoped somebody more knowledgeable with these techs could reproduce and pinpoint the culprit. I'm using t530 if that also plays any role. btw it is not possible to override default route in a dhcp connection. See bug 1140947. I'll try static routing to see if it helps. FYI static routing fixes the issue. Not ideal situation though. Also today I experienced a "hang" today again. From the type where one CPU is maxed out. But went to get a breakfast and after an hour I saw it calmed down and everything working properly. Not sure what could it be, the VM is a clean fedora used for running test code so no strange services installed. I am wondering if I can install some script checking CPU time every minute and log process cpu usage. If you have anything handy, I'd appreciate it as I've no good idea how to achieve that. This message is a reminder that Fedora 20 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 20. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '20'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 20 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component. (In reply to Aleksandar Kostadinov from comment #10) > So why NetworkManager on host is able to restore network when host is > suspended but running on guest, it's unable to restore network? IMO there's > some issue in the suspend/wake-up sequence. Maybe virtual network not up at > the time NM does what it does or DHCP server doing something strange. > > In any case, I hoped somebody more knowledgeable with these techs could > reproduce and pinpoint the culprit. I'm using t530 if that also plays any > role. Could you run "nmcli g log level debug" inside the guest, and then reproduce the issue, then attach "journalctl -b -u NetworkManager" output from the guest to this bug report? It seems I cannot reproduce anymore. At least didn't occur after you requested info. Closing. Thank you for debugging tip. It can definitely come in handy. FYI latest updates of fedora 22 guest under fedora 21 host. |