Why does Virtualbox's screen fail to redraw?

[pusha]

After some inactivity on the host, typically after allowing the screensaver (on the host) to trigger, when I log back in (still on the host), and try to start interacting with my VM in Virtualbox again, I find that the screen fail to redraw.

By failing to redraw I mean that the screen is not just blank, but copies whatever is in the framebuffer from the previous window that was displayed -- i.e. when I switch to Virtualbox, if I had Firefox open, I just get the (static) content of the previous window.

However, sometimes, if I wait some time, such as a few minutes, suddenly Virtualbox will redraw its screen and work as normal from that point. Half the time, no amount of time seems to make it start working again.

What is causing this? How can I mitigate it?

Host: Debian 9.13 Kernel (host): 4.9.0-15-amd64

Virtualbox version: Version 6.1.18 r142142 (Qt5.7.1)

Guest: Debian 10, with kernel 4.19.

[Bulkley]

I'm sure you noticed that Virtualbox is not in Debian's repositories. There's a reason for that. If you are determined to run it I suggest you find the version from MX Linux. Otherwise use qemu-kvm from the command line or one of the GUIs that use libvirt.

[pcalvert]

Virtualbox version: Version 6.1.18 r142142 (Qt5.7.1)

Are you sure about that? Mine reads "Version 6.1.18 r142142 (Qt5.6.1)".

How much RAM do you have, and how much RAM did you allocate to the VM?

Phil

[pusha]

Virtualbox version: Version 6.1.18 r142142 (Qt5.7.1)

Are you sure about that? Mine reads "Version 6.1.18 r142142 (Qt5.6.1)".

How much RAM do you have, and how much RAM did you allocate to the VM?

Phil

I'm sure, I copy/pasted the version string.

I have 32 GB and the VM has 8.

However, I can see that my VM is only using around 1 GB, and even if it did run out of memory, the screen would freeze while the OOM killer is triggered by the kernel -- eventually, usually, the system would resume. However, even while the screen is frozen when it is out of memory, there's no reason Virtualbox should fail to redraw the current framebuffer as is (yes, even while frozen). It should display whatever was in the frame buffer at the moment the VM froze.

Regardless, I can confirm with 100% certainty that this isn't an issue with memory.

[pusha]

I'm sure you noticed that Virtualbox is not in Debian's repositories. There's a reason for that. If you are determined to run it I suggest you find the version from MX Linux. Otherwise use qemu-kvm from the command line or one of the GUIs that use libvirt.

And what is the reason? Is there a reason to expect to have issues like I am having?

[pcalvert]

Host: Debian 9.13 Kernel (host): 4.9.0-15-amd64

Is there a good reason why you are using an old version of Debian as the host system? If not, then I recommend upgrading to Debian Buster. You may find that doing so solves your problem with VirtualBox.

Phil

[pusha]

Host: Debian 9.13 Kernel (host): 4.9.0-15-amd64

Is there a good reason why you are using an old version of Debian as the host system? If not, then I recommend upgrading to Debian Buster. You may find that doing so solves your problem with VirtualBox.

Phil

I've now upgraded to Debian 10.9. Kernel 4.19.0-16-amd64.

I have exactly the same problem.

[stevepusser]

Which video output is the guest set to use in VBox's settings? I think the least troublesome is VMSVGA.

I'm the guy that's been backporting the newer VBox from Sid for the MX repos. Debian adds a lot of patches, so that's another thing to look at if you're using the packages from Oracle.

[pcalvert]

I've now upgraded to Debian 10.9. Kernel 4.19.0-16-amd64.

I have exactly the same problem.

What is the output of this command?:

Code: Select all

cat /proc/sys/vm/swappiness

Phil