Ubuntu Guest On Win XP: CPU Utilization 100% During Network Communications

[alcohen]

I installed VirtualBox 2.1.0, then installed Ubuntu Intrepid from the iso. When updating packages from the repository, after a short while CPU utilization as reported on the host would go to 100%, 99% of which was taken by VirtualBox. Everything would freeze up. After 5-10 minutes or so, CPU utilization would drop back to normal and downloading would resume. I tried several virtual NICs in VirtualBox, none worked better.

I dropped back to VirtualBox 2.0.6, repeated the same exercise, and all worked properly.

[Len Smith]

I've seen this happen in Vista with an XP VM and is now happening with an Ubuntu VM as well.

[zos]

I am having exactly the same problem. As soon as I go to download updates the CPU maxes out. Stopping the update process returns the system to a usable state. Windows becomes exceptionally unresponsive. Running XP Pro service pack 3 as the host and Ubuntu 8.10 as the guest. Only during prolonged downloads does this occur. I don't feel that my firewall (comodo) is interfering but I wouldn't rule out anything. Seems like the translation is hitting the CPU really bad for some reason. Oh, I'm using NAT, but I think it happens in the other mode as well. I shall certainly try to see what I can do here.

[zos]

Change it from NAT to host interface and set the ethernet card to the etherlink-II. Should work fine, especially with DHCP. Otherwise if you are running static you'll likely need to assign the host a new IP. The NAT is doing something wrong here.....

Anyways I'm downloading the updates and typing this in Windows, so it should work. This would likely also fix the vista host/xp client issue.

[zos]

I should also add that this will break the shared folders. At least it does for me. The only workaround that would be obvious would be to just share the folder in the host and let the linux guest see it over the network, hopefully you'll hit the loopback first but I don't know exactly how the host interface works yet. It might just pass the packets straight to the card.

[zos]

I take all that back about the shared folders. I reinstalled the additions for linux and the shared drive is right back where it should be! :)

[Samson Luk]

@zosX, I am unable to download anything over the Internet (transfer rate very fast at the beginning but reduced to 0 and then wait forever after a few seconds) when changed to Host Interface mode although it did fixed the 100% cpu utilization issue on VirtualBox.exe. I am unable to complete Ubuntu software update of the VM guest as of this moment because either NAT or Host Interface mode can provide a solution.

[zos]

Ok. So that solves your CPU utilization issue, but (surprise) adds new issues. I'm guessing you are just running through a router. Might want to check and see of dhcp is working correctly. ping the gateway, router, etc. dhclient is the command on linux IIRC. sounds like something isn't routing right if the nic is handshaking with the router/hub. But who the hell knows. "It doesn't work" isn't really all that descriptive. If I understand correctly the host mode exposes the virtual machine to the network so you have to actually treat it as a new machine on your network. Though I could be totally wrong about that. While I could get ping to work in between the boxes there were some weird issues with connecting to the host OS via the LAN. (it looked like it just defaulted to the loopback IIRC). That should work though. Some routers will let anything define itself as a static ip without creating a route (my dlink is like that), as long as there is no conflict, but you'd have to point the DNS towards something that is valid (the router, etc).

-z-

[Samson Luk]

Correct, with Host Interface the VM just act like another computer (192.168.0.6) in the LAN, I am sure it is not routing related because if routing is not correct it should not work from the very beginning but not transferrate slow download then time out kind of symptoms. Today is better, a 23M Linux kernel update can have 50% downloaded before it stop...

~$ ifconfig
eth0      Link encap:Ethernet  HWaddr 08:00:27:ae:6d:74  
          inet addr:192.168.0.6  Bcast:192.168.0.255  Mask:255.255.255.0
          inet6 addr: fe80::a00:27ff:feae:6d74/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:536 errors:0 dropped:0 overruns:0 frame:0
          TX packets:462 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:577650 (577.6 KB)  TX bytes:39985 (39.9 KB)
          Interrupt:11 Base address:0xc020 

Can see the gateway router

:~$ arp -a
? (192.168.0.1) at 00:10:db:05:aa:40 [ether] on eth0

routing table is correct

:~$ route 
Kernel IP routing table
Destination     Gateway         Genmask            Flags Metric Ref   Use  Iface
192.168.0.0     *                    255.255.255.0    U      1         0       0     eth0
link-local         *                    255.255.0.0        U      1000   0       0     eth0
default            192.168.0.1    0.0.0.0                UG   0         0       0     eth0

ping to ubuntu update site just fine...

:~$ ping hk.archive.ubuntu.com
PING hk.archive.ubuntu.com (91.189.88.45) 56(84) bytes of data.
64 bytes from prat.canonical.com (91.189.88.45): icmp_seq=1 ttl=52 time=315 ms
64 bytes from prat.canonical.com (91.189.88.45): icmp_seq=2 ttl=52 time=323 ms
64 bytes from prat.canonical.com (91.189.88.45): icmp_seq=3 ttl=52 time=329 ms
64 bytes from prat.canonical.com (91.189.88.45): icmp_seq=4 ttl=52 time=338 ms
64 bytes from prat.canonical.com (91.189.88.45): icmp_seq=5 ttl=52 time=350 ms
64 bytes from prat.canonical.com (91.189.88.45): icmp_seq=6 ttl=52 time=350 ms
64 bytes from prat.canonical.com (91.189.88.45): icmp_seq=7 ttl=52 time=330 ms
64 bytes from prat.canonical.com (91.189.88.45): icmp_seq=8 ttl=52 time=321 ms
64 bytes from prat.canonical.com (91.189.88.45): icmp_seq=9 ttl=52 time=313 ms
64 bytes from prat.canonical.com (91.189.88.45): icmp_seq=10 ttl=52 time=322 ms
64 bytes from prat.canonical.com (91.189.88.45): icmp_seq=11 ttl=52 time=327 ms
64 bytes from prat.canonical.com (91.189.88.45): icmp_seq=12 ttl=52 time=331 ms
64 bytes from prat.canonical.com (91.189.88.45): icmp_seq=13 ttl=52 time=339 ms
64 bytes from prat.canonical.com (91.189.88.45): icmp_seq=14 ttl=52 time=324 ms
64 bytes from prat.canonical.com (91.189.88.45): icmp_seq=15 ttl=52 time=306 ms
64 bytes from prat.canonical.com (91.189.88.45): icmp_seq=16 ttl=52 time=320 ms
64 bytes from prat.canonical.com (91.189.88.45): icmp_seq=17 ttl=52 time=327 ms
64 bytes from prat.canonical.com (91.189.88.45): icmp_seq=18 ttl=52 time=308 ms
64 bytes from prat.canonical.com (91.189.88.45): icmp_seq=19 ttl=52 time=350 ms
^C
--- hk.archive.ubuntu.com ping statistics ---
19 packets transmitted, 19 received, 0% packet loss, time 18134ms
rtt min/avg/max/mdev = 306.650/328.044/350.795/12.873 ms

[Frank Mehnert]

Please reopen if still relevant with VBox 4.1.6.