Opened 5 years ago
Last modified 22 months ago
#19358 new defect
VMs lose bridged network connection after host suspend/resume
Reported by: | VeHav2GoVeeper | Owned by: | |
---|---|---|---|
Component: | network | Version: | VirtualBox 6.1.4 |
Keywords: | bridge bridged disconnected | Cc: | |
Guest type: | all | Host type: | Windows |
Description
This doesn't happen every time, but often enough to become frustrating: when I suspend/resume the host, all of the guests (Windows and Linux) are unable to communicate over the bridged network.
What does not work:
- suspending/resuming the guest
- restarting the guest OS network services
- restarting the guest OS
- disabling/enabling the guest's network adapter
- disabling/enabling the host's network adapter that is bridged
- disabling/enabling the vbox bridging driver on the host's network adapter
One thing that did work:
- connect alternate network adapter on host (eg.: wireless) and set as bridge for VM
Aside from that, the only thing that fully works is to reboot the host, but I have several passwords to enter and dozens of applications to run in order to get my environment setup, which makes frequent rebooting untenable.
This may also provide a clue: when I enabled the host's wireless adapter, the host was not able to receive an IP lease from the router's DHCP server, I had to key in a static IP for the host.
Is there a service or executable I can restart or run to kickstart the bridged networking?
Attachments (5)
Change History (10)
by , 5 years ago
Attachment: | Windows 10 1809-2020-02-22-08-04-51.log added |
---|
by , 5 years ago
Attachment: | Windows 10 1809-2020-02-28-08-35-31.log added |
---|
by , 5 years ago
Attachment: | Windows 10 1809-2020-02-28-08-47-15.log added |
---|
by , 5 years ago
Attachment: | Windows 10 1809-2020-02-28-08-47-19.log added |
---|
by , 5 years ago
Attachment: | Windows 10 1809-2020-02-28-08-51-11.log added |
---|
comment:2 by , 4 years ago
What helps is to change the promiscuous mode in the extended network settings back and forth. Hope this helps.
comment:3 by , 3 years ago
I have come across similar behaviour and it's happening on a NAT Network.
Still not able to find what's causing it but changing the network to Bridged and then back to NAT Network seems to be solving the issue temporarily until it happens again.
comment:4 by , 3 years ago
I may have found a solution to this and possibly the reason it happens.
Changing the adapter type to PCnet-FAST III (Am79C973) seems to be working for me. The connection is not being lost anymore.
The previous adapter type I was using was Intel PRO/1000 MT Desktop (82540EM). If a dev would like to look into this further, let me know and I can provide more information.
comment:5 by , 22 months ago
It is now 1/2023. I am running Virtual Box 7.0.4 on Windows 10 Pro (Intel-based PC). I have 2 guests running (Android x86 and Ubuntu 22). And I must sadly report that this issue remains all of these years later.
Thankfully, the suggestion by harrisp 19 months ago is something of a help. But I have since discovered that even with PCnet-Fast in place instead of Intel Pro, loss of network (either thru ethernet unplugged or router rebooted) causes all of the guests running on my Windows 10 host to get their networks messed up - while the host itself has recovered perfectly...
Unlike when using the Intel Pro, I have found that I do NOT need to reboot the host. But I have to terminate and re-start ALL of the running guests on that host in order to recover their network connectivity. Interestingly, at least on some occasions after the host's network has recovered, I found that connectivity between host and guests was ok (ie, I could ping from the host and get replies). However, the guests were NOT able to connect any further so pings from anywhere else on the LAN other than the host would still fail.
I guess what I will have to do is create a Windows Event Manager task linked to the restoration of the LAN at the host level and have that trigger a termination and re-start of the guests.
This seems better than a reboot of the host. But not by much! This really needs attention!
https://www.virtualbox.org/ticket/14374#comment:41] seems to work:
taskkill /t /f /im VboxNetDHCP.exe