[Solved] Windows 10 guest freezes periodically

[skoehler]

Since recently, I'm having troubles with my Windows 10 guest. It freezes periodically and then, after a few seconds, resumes normal operation. Then it freezes again after a few seconds, and so on ....
The Windows Event Log contains several entries from the storahci driver, saying that the Device \Device\RaidPort0 was reset. That is follows by an entry in the Event Log stating that an I/O request was repeated.

It seems like the Windows Guest locks up due to some I/O that doesn't complete, and then the (virtual SATA controller+harddisk) is being reset and the I/O request is repeated.

The problem only seems to be happening with my Windows 10 guest at work (Host is Ubuntu 17.04, VirtualBox 5.1.22, Intel i5-4690 CPU).
My Windows 10 guest at home (Gentoo Linux, same virtualbox version, Skylake CPU) does not seem to have this problem.

Does anybody have similar issues or maybe knows how to resolve them?

[mpack]

Please provide a VM log file. With the VM fully shut down, right click it in GUI. Select "Show Log" and save "VBox.log" (ONLY) to a zip file. Attach the zip here.

[skoehler]

Find the log attached.

[mpack]

You have a 4-core CPU and have assigned all 4 cores to the guest. Naturally this will cause problems - you have effectively crippled the host, which is where VirtualBox is. Plus every other host background function that can't run (in time).

Try assigning two cores to the guest. Max.

[skoehler]

You have assigned all 4 CPU cores to the guest. Naturally this will cause problems. Try assigning two cores to the guest.

Could you elaborate on the "naturally"? Cause I dont see why it should cause problems.

[mpack]

No, I don't feel like having that discussion, perhaps others might. IMHO simple arithmetic ought to tell you what the problem is: 4-4 = 0. Or "you can't have your cake and eat it".

[skoehler]

You're still not making sense.

Anyhow, it also happens with only 2 cores assigned to the guest.

[socratis]

You're still not making sense.

Here's something that might:

Why is it a bad idea to allocate as many VCPUs as there are physical CPUs?

You cannot have the best of both worlds. Most modern Intel CPUs have VT-x preemption timers, which VirtualBox has been using for years now. This lets us run chunks of guest code and still get interrupted to run host code depending on how we program the preemption timer. However, the question is not whether we can or cannot interrupt guest code, we normally can. The problem is that there are tasks that require to be run in reasonable frequency & amount of time both on the host *and* the guest. If you starve the host or guest of interrupts or introduce latency because there simply isn't enough compute power available, you will be creating bottlenecks.

Getting in and out of executing guest code via VT-x is still quite an expensive operation. We call it a world-switch or world round-trip, (i.e. VM-entry, execute guest, VM-exit). This is done in ring-0 (kernel) on the host, sometimes (especially on Windows hosts) we are forced to return all the way to ring-3 sometimes in order to satisfy DPC (Deferred Procedure Call) latency. Overall, you're going to have strange latencies introduced in unexpected places if you "overcommit". It is totally possible to run 4 VCPU VM on a 4 CPU host (I do it on my own my Linux dev box sometimes) but it is not something you should be doing if you care about reasonable performance; in extreme cases of overcommitment you may encounter program misbehavior (like when disk requests times out) which the programs are never designed to handle. In the not so severe case you may end up with some strange timeouts but not fatal errors.

[skoehler]

Thank you, socratis. But the issue keeps happening with only 3 or 2 cores assigned to the Windows 10 Guest. I am able to reproduce the issue quite reliably. Sometimes it happens during bootup, sometimes it happens during login, and sometimes it happens when I open up the Event Log Viewer. And, if I happen to be lucky, I just need to run some I/O intensive program (Crystal Disk Mark, for example) to see resets of the AHCI disk/controller in the Event Log. And as I said this all happens even if I assign only 2 of 4 cores to the VM. (The host CPU has 4 cores without hyperthreading)

There was a time when the Windows Guest was running reliably (even with 4 cores assigned). The issues started appearing a while ago. Either it was the upgrade to Ubuntu 17.04, or a VirtualBox upgrade. I should also mention that I use Ubuntu's lowlatency kernel variant.

Linux bali 4.10.0-22-lowlatency #24-Ubuntu SMP PREEMPT Mon May 22 18:59:21 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux

You're not a big help, so I will try to investigate myself (switch to normal kernel, downgrade VirtualBox, ...).

[socratis]

You're not a big help, so I will try to investigate myself

Seriously? I was only pointing you to your misunderstanding about the 4/4 CPUs issue. What mpack was apparently trying to explain to you in vain. I didn't even deal with your problem, did I? I had a couple of ideas, but you seem to prefer hunting. Buona fortuna!

[skoehler]

You're not a big help, so I will try to investigate myself

Seriously?

Sorry if you feel personally attacked. I thanked you for your explanation, because it was very insightful.
But after all, mpack hasn't been very helpful and in english, "you" does not always refer to a single person, AFAIK.

[skoehler]

As for the "hey idiot, it's simple math 4-4=0" statement. We all know that modern operation system have a feature called preemption. This also applies to virtual machines. It is true that the host has to perform the actual IO and thus needs CPU time to do that. Then again, the guest did not and cannot (due to preemption) take away all CPU time from the host. Latencies may be larger, but the guest was hanging for several seconds before doing the AHCI reset. During that time, it did not take CPU time and CPU utilization was generally low when the issue occurred. Again, I thank socratis for posting some information about potential issues with preemption when all cores are assigned.

Anyhow, I have now switched back to Ubuntu's generic kernel. The issue cannot be reproduced anymore (even with all 4 cores assigned to the guest). So it seems the lowlatency kernel might have been the issue. I was using the lowlatency kernel with the previous version of Ubuntu and I had no such issues. So I guess the issue came along with the Ubuntu upgrade. It also explains, why nobody else was reporting the issue (there might not be many people who switch to the lowlatency kernel).

Most importantly, if the issue was simple math as suggested my mpack, then VirtualBox should warn the user about the negative sideeffects of assigning all 4 cores. For years now, the VirtualBox UI has warned users when they assign more cores than the number of host CPU cores (e.g. on hosts which offer 2 threads per CPU core). Then again, there does not seem to be any need for a new warning as the issue is resolved now.

[mpack]

I was not helpful because I don't care to help people who are simply too lazy (physically or mentally) to help themselves. For example, the information you asked me for has been discussed many times and hence easily found by searching. Had you done so you might have found the information given on the subject by the devs. But no, you preferred to have me spoon feed that info to you.

And the relevance of your comments on pre-emptive switching escapes me. The question was not "can CPU cores be shared", it was "why might sharing CPU cores result in a VM which freezes periodically": it says so right in the topic title which you chose. Obviously if a core is shared then it's opened to being hogged by processes in both host or guest. 4-4=0 unshared cores. Am I getting this past your comprehension barrier now?

[skoehler]

And the relevance of your comments on pre-emptive switching escapes me. The question was not "can CPU cores be shared", it was "why might sharing CPU cores result in a VM which freezes periodically": it says so right in the topic title which you chose. Obviously if a core is shared then it's opened to being hogged by processes in both host or guest. 4-4=0 unshared cores. Am I getting this past your comprehension barrier now?

Of course, virtualbox has to perform certain tasks at a reasonable frequency. That's what can be achieved through preempting the guest OS. Am I getting past your comprehension barrier now?

[socratis]

That's what can be achieved through preempting the guest OS.

That's under normal circumstances, where the OS can make a different set of assumptions ^[1]. I'll requote a specific part of Ramshankar's explanation, with a little bit of highlight:

in extreme cases of overcommitment you may encounter program misbehavior (like when disk requests times out) which the programs are never designed to handle.

That's why it's never a good suggestion to use 4/4, or n/n CPUs ^[2]. Most extreme cases we suggest (n-1)/n. Now, I've used (2*n)/n, but that was arithmetic calculations only. And in case you're wondering 2*n included the logical CPUs, not just the physical.

If you are satisfied with your solution, please mark the thread as [Solved] and close it...

---

[1]: Like your low latency kernel. Your (or the kernel's) assumption is that they are the master's of the computer. And they expect things with a very, very specific latency. If it doesn't happen, something hits the fan. Big time...

[2]: That's a division, not a subtraction...