Live adapter change not working

[Sasquatch]

Switching the attached adapter type doesn't work until the VM is shut down and started again, making the option to change the settings while the VM is running useless.

The problem is that when you swap Bridged adapter from one NIC to another, the NIC that was set upon VM start is used instead, despite what is set after VM start.

Simple test: get a VM and attach it to a wired NIC while the Host is connected through wireless. Start the VM, switch it to wifi and the Guest will not be able to access the network in any way. Hook it to a cable, and it will work, even though the actual NIC to use should be the wireless one (because you changed that after the VM started).

I have not tested the method to change the main attached method, e.g. from Bridged to NAT. This problem was already mentioned on the forums during beta 1, repeated for both beta 2 and beta 3. The log file doesn't even show the change in adapter setting.

[Sasquatch]

Log of run when switching from wireless to wired.

[MrX1980]

I agree to this.
On a PC with 3 network cards I have to reboot the PC after changing the network card in bridged mode to take affect.
(It could be that shutting down the VM and restart all VB programs does the same, but only restarting the VM is not enough)
Host/Guest: Win 7 Ultimate x64/x32

[Sasquatch]

Just tested to switch from Bridged to NAT, that works. So the problem is the Bridged adapter hooks. The config changes, but it doesn't listen or otherwise hook itself to the new adapter until it's reinitialized by a restart of the VM.

[Frank Mehnert]

Confirmed. Sorry for the late response. The fix is very easy but we have to check for side effects first.

[Frank Mehnert]

First, the patch will be included in the next release.

Second, Sasquatch, not related but you should apply the fix from #6250 as it applies to your host as well.

[Sasquatch]

Sorry frank, but on what basis do you think that bug #6250 applies to my host too? Only because I run 2.6.32 kernel? I do not experience any slowness on both my PC (AMD FX-60 CPU, runs Jaunty 32 bit with the Ubuntu Kernel PPA kernel, currently 2.6.33) and my laptop (Intel C2D P8700 CPU, runs Karmic 64 bit, stock kernel). Nor do I see the entries mentioned in that bug report in my logs. Only the Asynchronous CPU timer.

So, I'm not going to apply some 'patch' that I don't even need.

[Frank Mehnert]

You can be assured that I do not select random people to do some strange tests. Your VBox.log file clearly shows that the GIP mode (the GIP is a memory area containing the central time for all VBox processes) on your host is asynchronous (that means that the TSC counters of the CPU cores are not synchron) and our timer code is definitely wrong on such hosts with a Linux kernel >= 2.6.31. The assumption is that a timer which is started on one CPU core will remain active on exactly this CPU core. Starting with Linux 2.6.31, this assumption is no longer true because the semantics of mod_timer() changed: Now a timer can migrate to another CPU and our timer update code will not handle this case correctly.

This will lead to strange timing problems, especially for SMP guests if the host has no other load than one VM. The fix will be included in the next VBox release so there is no need that you apply it manually. It was just a suggestion as I think that the fix will improve the VBox behavior on some hosts, therefore my hint but don't mind.

[Sasquatch]

Good, because I don't use SMP on my VMs anyway. Reason: my PC is not AMD-V capable and I share the VMs between PC and laptop. I've done this for quite some time and never noticed anything wrong with the performance of the VMs.