[Solved] Linux Mint 18: Windows 7 guest kills host network at startup

[NginUS]

VirtualBox 5.0.32_Ubuntu r112930, Extension Pack not installed.

When I boot the Windows 7 guest, the Linux Mint 18 host's network hiccups just enough to kill several of my Chrome tabs & they have to be reloaded.

I've tried both "Paravirtualized" & "Intel Pro 1000 MT Desktop" adapters & the behavior persists either way.

I've also tried using both "DHCP" & "Static" IP address assignment on both of the aforementioned adapter types, to no avail.

I haven't tried NAT'ing the guest, & would prefer to stay bridged.

[socratis]

VirtualBox 5.0.32_Ubuntu r112930

It looks like you're using the distro's fork version of VirtualBox. You can either ask in their forums for help, or completely remove/uninstall/delete/purge their version and install the official version from the Downloads section of VirtualBox (https://www.virtualbox.org/wiki/Downloads).

[NginUS]

completely purge their version

I've added the official repo, & now see the current version in Synaptic. But before I go purging, I want to be sure I can get the VM up & running again- so I have to ask to be sure...

Do I need to export an .ova first?
Should I uninstall the guest additions beforehand?

Is there a preferred procedure I should follow to preserve the guest?


---Thanks

[socratis]

Do I need to export an .ova first?

Nope, you don't. Just like if you go from OpenOffice to LibreOffice you don't have to export your documents/spreadsheets/presentations.

Should I uninstall the guest additions beforehand?

You will need to do that at some point. If you do it before or after you've updated your main app, doesn't really matter. What matters is that you update the GAs with the ones that come bundled with VirtualBox.

Is there a preferred procedure I should follow to preserve the guest?

Yes, the simplest! Do nothing
Of course a backup never hurt anyone, but I've heard of no stories of guests getting lost/corrupted in similar scenarios. If you want to play it safe (a wise choice), read: Moving a VM. You don't need to export or import anything, just a folder copy.

[NginUS]

It still happens, even with the official package installed as per the Virtualbox website...

Any other ideas to try??

This really sucks.

[socratis]

When I boot the Windows 7 guest, the Linux Mint 18 host's network hiccups just enough to kill several of my Chrome tabs & they have to be reloaded.

First of all I'd like a definition of the problem. What's a "hiccup"? And why Chrome specifically? Are you doing some streaming which gets interrupted? Have you tried anything else streaming?

Second, I'd stick with the defaults; that would be "NAT" and the "Intel PRO 1000/MT Desktop" adapter. Follow a "start from cold-boot"/"observe error"/"shutdown" cycle. With the VM shut down completely (not paused or saved), right-click on the VM in the VirtualBox Manager and select "Show Log". Save the first "VBox.log" only, ZIP it and attach it to your response (see the "Upload attachment" tab below the reply form).

Third, since you said you'd prefer Bridged mode, change the network mode from NAT to Bridged and redo the whole startup / problem / shutdown / zip & post log, again.

And if you could tell me some more details about your network setup, mainly if you're using WiFi or wired for the Bridged mode and if you've tried both of them.

[NginUS]

What's a "hiccup"? And why Chrome specifically? Are you doing some streaming which gets interrupted? Have you tried anything else streaming?

What I call a 'hiccup' is what appears to be the host's network temporarily disconnecting from the internet. As evidenced by a few Chrome tabs changing to the 'grimace face' icon where the favicon should be. Also these affected pages no longer display the website page they should but rather some Chrome error page stating something to the effect of this web page cannot be loaded or some such. The tabs it happens on IIRC are Netflix, the Facebook game 'Words with Friends', & maybe a couple others I don't recall at the moment. I'll try to get a screenshot next time to post here. As for streaming, I don't remember if I've ever had Amarok playing webradio when it's happened- at least I don't remember specifically that it was affected as well.

Second, I'd stick with the defaults; that would be "NAT" and the "Intel PRO 1000/MT Desktop" adapter.

I've just switched from "Bridged" to "NAT", & apparently the NFS client in the guest is indeed still able to connect to the NFS server on the host without additional reconfiguration, which is a relief. Paravirtualized still works, so I don't see a need to change that at the moment- I will as the next step in troubleshooting if the errant behavior persists.

Follow a "start from cold-boot"/"observe error"/"shutdown" cycle. With the VM shut down completely (not paused or saved), right-click on the VM in the VirtualBox Manager and select "Show Log". Save the first "VBox.log" only, ZIP it and attach it to your response (see the "Upload attachment" tab below the reply form).

since you said you'd prefer Bridged mode, change the network mode from NAT to Bridged and redo the whole startup / problem / shutdown / zip & post log, again.

Right now I have the one log [1], will keep this in mind for the future.

if you could tell me some more details about your network setup, mainly if you're using WiFi or wired for the Bridged mode and if you've tried both of them.

The host is a laptop which connects over WiFi. While I do also have a wired port, I don't have a cable with which to test from my room. It's more hassle than it's worth at the moment to physically relocate to within reach of the router, where I'd have to use a cable currently in use to connect the Smart TV. I won't be testing the wired connection unless it's absolutely necessary, a last resort. Both WiFi & Wired connections are present in identical guest interfaces- both configured exactly the same, except that the wired one hasn't had a network type (Home, Work, Public) assigned, as it's never been active. In each of the Windows adapters, IPv6 is unchecked, & now, since changing to "NAT" from "Bridged", the IPv4 configurations are set to "Automatic" on both IP Address & DNS. Their IP Address & DNS had been set as "Static" when they were "Bridged" prior to tonight.

[1]:
http://sebsauvage.net/paste/?4892992155 ... UDoREweNk=

[socratis]

You might have missed that part:

Save the first "VBox.log" only, ZIP it and attach it to your response (see the "Upload attachment" tab below the reply form).

now, since changing to "NAT" from "Bridged", the IPv4 configurations are set to "Automatic" on both IP Address & DNS.

When you had it in Bridged mode you had static IPs? Why? But more importantly, since you switched to NAT (which you were reluctant to previously do), do you still see the hiccups? Or is everything working as it should?

And finally,

Paravirtualized still works, so I don't see a need to change that at the moment

Any specific reason why you chose to deviate from the template defaults?

BTW, WiFi and wired do not behave identically as far as bridging is concerned. In fact WiFi is not supposed to allow bridging. It may or may not work. With or without problems.

[NginUS]

You might have missed that part:

Save the first "VBox.log" only, ZIP it and attach it to your response (see the "Upload attachment" tab below the reply form).

Oops, yea- skimmed right past that. I had already booted 1 or 2x beyond the time when the network hiccupped so that desired one was lost, apparently.

since you switched to NAT (which you were reluctant to previously do), do you still see the hiccups? Or is everything working as it should?

Even when it was set to the failing "Bridged" mode, it wouldn't exhibit the errant behavior every time it booted. Nor would it after any type of action I'd try and do to see if I could command it to be recreated. Seems totally random- which, I guess shouldn't be the case, but I've not tested stuff like router-issued leases because they were "Static" addresses & shouldn't be affected. But the time between symptoms leads me to wonder about what kind of network changes happen relatively infrequently. Essentially I have no idea what to do to see if it'll happen again aside form waiting a couple days & boot, in which case it's likely to happen.
Also, being that I've missed opportunities to do so thus far, I'm more aware of the need to get relevant logs. And screenshots of the exact error displayed in Chrome when the hiccup occurs on the host. In the forefront of my mind tonight- hopefully still when it matters later. But, to answer your question, I guess I'll know in a day or 2 then post back here.

Paravirtualized still works, so I don't see a need to change that at the moment

Any specific reason why you chose to deviate from the template defaults?

When I used to regularly work with the ProxmoxVE distro, I got in the habit of using virtio whenever possible, since as I understand it lessens load on the host by using paravirtualization as opposed to fully software virtualized components. As such, I opt to use this in this case with the hope of minimizing (even in theory) the resources necessary to run the guest OS.

BTW, WiFi and wired do not behave identically as far as bridging is concerned. In fact WiFi is not supposed to allow bridging. It may or may not work. With or without problems.

This is new information to me. I had no idea. For the last 6 months at least, I've been using WiFi as my primary source of internet connectivity for the first time in- well, ever.

[socratis]

BTW, WiFi and wired do not behave identically as far as bridging is concerned. In fact WiFi is not supposed to allow bridging. It may or may not work. With or without problems.

This is new information to me. I had no idea. For the last 6 months at least, I've been using WiFi as my primary source of internet connectivity for the first time in- well, ever.

I highlighted the part that you may have missed. I'm not talking about using WiFi. I'm talking about using Bridged over WiFi for your VMs. For more details, please check 6.5. Bridged networking, the second Note.

[NginUS]

Using NAT rather than Bridged seems to have solved the issue.