#13873 closed defect (invalid)
Issue With Hostonly Adapter After Suspend
回報者: | jpulec | 負責人: | |
---|---|---|---|
元件: | network/hostif | 版本: | VirtualBox 4.3.18 |
關鍵字: | 副本: | ||
Guest type: | Linux | Host type: | Linux |
描述
Recently I have begun to notice that after suspending my host system (Ubuntu 14.10) while having virtual box running a guest (Ubuntu 12.04), I can no longer connect from my host.
I'm using Vagrant, so the guest is setup with NAT and a hostonly interface. After resuming, the NAT connection seems to work fine on the guest. I can still ping google.com. But if I try to ping the guest from the host there is no connection. However if I restart the VM a couple of times, it usually seems to start working normally again.
Should also note that there seems to be a LOT of vboxnet interfaces defined on my host machine (vboxnet0-vboxnet14) so maybe the issue lies somewhere there.
附加檔案 (1)
更動歷史 (19)
comment:2 10 年 前 由 編輯
I don't get it how the vboxnetX interface could steal a DHCP-provided IP address. The vboxnetX address should not interfere the address range of the host interface (in your case enp3s0).
comment:3 10 年 前 由 編輯
Note I just corrected my above description. I had written that my normal host interface (enp3s0) got it's IP address via DHCP but actually it was set as a manual static IP in NetworkManager via the GNOME applet. The fundamental problem remains the same. That address gets assigned somehow to the vboxnet0 interface after a resume and enp3s0 gets left unassigned.
comment:4 9 年 前 由 編輯
I have similar issue, Fedora 22 / 4.0.2-300.fc22.x86_64 running VirtualBox-4.3-4.3.28_100309_fedora18-1.x86_64.
On resume the vboxnet0 interface exists, but has no ip address i.e.
3: vboxnet0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UNKNOWN group default qlen 1000 link/ether 0a:00:27:00:00:00 brd ff:ff:ff:ff:ff:ff
To get the interface back up and running i have to shutdown the VM's, close the vbox manager and start it and start a VM, then i get my host IP (host-only adapter) back
3: vboxnet0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UNKNOWN group default qlen 1000 link/ether 0a:00:27:00:00:00 brd ff:ff:ff:ff:ff:ff inet 192.168.56.1/24 brd 192.168.56.255 scope global vboxnet0 valid_lft forever preferred_lft forever inet6 fe80::800:27ff:fe00:0/64 scope link valid_lft forever preferred_lft forever
Is there a better/simpler way, a command i can run upon resume to do this?
comment:5 9 年 前 由 編輯
Also, on resume, vbox thinks the interface is available i.e.
# vboxmanage list hostonlyifs Name: vboxnet0 GUID: 786f6276-656e-4074-8000-0a0027000000 DHCP: Disabled IPAddress: 192.168.56.1 NetworkMask: 255.255.255.0 IPV6Address: fe80:0000:0000:0000:0800:27ff:fe00:0000 IPV6NetworkMaskPrefixLength: 64 HardwareAddress: 0a:00:27:00:00:00 MediumType: Ethernet Status: Up VBoxNetworkName: HostInterfaceNetworking-vboxnet0
跟進: 8 comment:7 9 年 前 由 編輯
Same story. Ubuntu 64 15.04. Fresh machine install. Using Vagrant to manage the box.
I'd give you the VirtualBox version too, but you guys decided it would be best to not allow people to copy-paste it off the About box.
comment:8 9 年 前 由 編輯
Replying to HetMes:
I'd give you the VirtualBox version too, but you guys decided it would be best to not allow people to copy-paste it off the About box.
Yes, and it's so complicated to write 6 digits/letters manually...
comment:9 9 年 前 由 編輯
Same issue here. Running vbox 4.3.28 r100309 vagrant 1.7.2 ubuntu 15.04 kernel 3.19.0-18-generic
comment:10 9 年 前 由 編輯
I seem to be having a similar or same issue while running vbox on Debian Jessie with XFCE with latest updates on Dell Precision 4700. Here's what I see:
When I don't start vbox, I am able to suspend and resume without issues. Debian works fine. However, when I start vbox which has a NAT network and a host-only network (vboxnet0) defined, in my network manager I see a vboxnet0 connection appear. So far so good, but when I close vbox manager, that connection (interface?) stays around and doesn't go away until I reboot (logout/login doesn't help).
When I try to suspend / resume, in some cases the suspend doesn't work (even if vbox is not running - but vboxnet0 is still around), in other cases resume doesn't work, in other cases resume happens but network manager tries to connect the vboxnet0 which it cannot.
As others have posted, I also have the issue of the virtual guest not being available after resume through the host-only interface. This is very challenging as a number of VMs I run use both NAT and host-only. So my workaround is to use the VMs but shutdown the PC (I do not suspend - as vboxnet0 interface is still around even if I close vbox and resume is flaky).
If I can provide any information, please let me know. Thank you very much for your support. I would log a Debian bug but since I am not using the package from Debian repository, I felt it was probably best to share my experience here.
Thank you.
comment:12 9 年 前 由 編輯
What is your network configuration on the host (network manager, systemd, etc)? What does your syslog says upon resume? This smells like the host misconfigures the network on resume. VirtualBox itself shouldn't do anything funny to the interface, not to mention somehow learning and "stealing" your primary static IP.
comment:13 9 年 前 由 編輯
I have a similar problem on a Windows 7 host with an Ubuntu 14.04 guest, but let me know if it should be a separate bug. The VM has two virtual NICs: the first one is NAT and the second one is host-only. On the host-only network both the guest and host have static IP addresses. When I suspend and then resume the host the NAT interface continues working but the host-only network no longer works. Both host and guest think that the network is available but cannot ping each other (host unreachable).
comment:14 9 年 前 由 編輯
I have similar problem, but I've found a workaround without restarting the VM. Just detach and re-attach the network adapter would work for me.
comment:15 9 年 前 由 編輯
I have the same problem (vboxnet interface disappearing after host goes to sleep / resumes).
- Host OS: Ubuntu 15.04 64 bit
- VBox version: 4.3.26_Ubuntu r98988
The interface is visible with all the right parameters if I do "vboxmanage list hostonlyifs", however it is absent from ifconfig / can't use it to connect to the VMs. Shutting down the VMs *and* the VBox GUI and restarting them fixes the problem.
Other tickets which seem to describe the same / related problem:
comment:16 9 年 前 由 編輯
I think I have a potential solution for those of you running NetworkManager.
- Host OS: Arch Linux, 64 bit
- Kernel: 4.1.6
- VBox: 5.0.2
- NM: 1.0.6
I started seeing this problem a few days ago, shortly after switching from Wicd to NM. Nothing else changed on my host, so vushakov's comment stood out to me. Looking through my system logs, I saw the following just before a suspend:
Sep 11 19:32:02 hostname NetworkManager[440]: <info> (vboxnet0): device state change: activated -> unmanaged (reason 'sleeping') [100 10 37]
NM never tries to bring the device back up, and I'm guessing VBox never looks at it unless its adding or removing a VM. If so, this would explain why restarting the VMs or detaching/attaching the network adapter seems to (temporarily) resolve the issue.
To resolve this, I added the following to /etc/NetworkManager/NetworkManager.conf:
[keyfile] unmanaged-devices=interface-name:vboxnet0
Note - after updating the config, NM will change vboxnet0's state back to 'unmanaged' (just like it does when suspending), but it shouldn't touch it from there on out. Just use one of the above mentioned workarounds one last time, and you should be good to go.
comment:17 9 年 前 由 編輯
I also have this issue on an Ubuntu 15.04 x86_64 host with VirtualBox 5.0.10 r104061 and a Fedora Core 22 guest.
The fix suggested by @zwolber worked for me. I had multiple vboxnet<n>
interfaces, so I needed to use
[keyfile] unmanaged-devices=interface-name:vboxnet0;interface-name:vboxnet1;interface-name:vboxnet2
(you need all the unmanaged devices on a single line) in /etc/NetworkManager/NetworkManager.conf. According to https://mail.gnome.org/archives/networkmanager-list/2015-January/msg00084.html, more recent versions of NetworkManager might support the more robust
[keyfile] unmanaged-devices=interface-name:vboxnet*
instead, to match all vboxnet<n>
interfaces, but that did not work for me, so instead I had to list all my host-only interfaces as you see above.
I had to reboot to get the NetworkManager.conf changes go take effect; restarting NetworkManager did not work for me.
I was using a workaround before applying @zwolber's NetworkManager fix. This workaround will hopefully work for VirtualBox running on any OS, since it doesn't have anything to do with NetworkManager: if you reconfigure a host-only interface in the main VirtualBox GUI, VirtualBox will restart all of the host-only interfaces. You don't actually need to change any settings, just open the edit dialog and then close it immediately. The menu sequence in the VirtualBox GUI is
File -> Preferences -> Network -> Host-only Networks -> <wrench icon> -> OK -> OK
Sometimes NetworkManager was crashing for me on suspend; in Ubuntu you can restart it with
sudo systemctl restart network-manager.service
Restart NetworkManager before applying the "reconfigure host-only interface" workaround, if you are using NetworkManager and it crashed.
comment:18 9 年 前 由 編輯
狀態: | new → closed |
---|---|
處理結果: | → invalid |
This is a problem with Network Manager.
The problem doesn't happen on Ubuntu 14.04 with network-manager 0.9.8.8-0ubuntu7.2. When host-only interface is create, network manager ignores it.
The problem does manifest on Ubuntu 15.04 with network-manager 0.9.10.0-4ubuntu15.3. There network manager tries to manage the interface, removes configured IP address on suspend and then doesn't know what to do on resume, so the interface remains not properly configured. I guess Ubuntu 14.10 from the original report developed the problem when NM package was upgraded to 0.9.10 (while 14.04 LTS stayed with 0.9.8).
Please, file a bug report with network manager. Skimming through Ubuntu changelog for it I see quite a bit of patches to ignore (or to not ignore) specific kinds of interfaces, so it seems it wouldn't be the first time NM tries to touch something it shouldn't have.
This problem happens to me also. I suspect it is reproducible for anybody. I am using an up-to-date Arch host with kernel 3.19.2-1-ARCH + VB 4.3.26-2.