[Virtualbox] Display issues with VBoxSVGA Controller?

My hardware:

NVIDIA Corporation GP106GL [Quadro P2000]
Samsung Electronics Co Ltd NVMe SSD Controller SM981/PM981

I installed my first Guest OS (Linux Mint 19.2 Mate) via Virtualbox and it went all fine. I was strictly following the manual. Then I realized I can't see if TRIM is available/enabled, since my Mint was installed with a setting for a "regular HDD".

The following line within my Mint (Guest OS) returns an empty string:

$ sudo hdparm -I /dev/sda | grep TRIM

Then I checked SSD setting within the properties of my Storage and then I started to face the same issues over and over again.

Now my Mint seems to have a problem with generating an image on screen:

I re-installed all over again several times with the same outcome (I always select "SSD" within the properties) - after installation, my Mint always looks as the image above. I use the following settings:

Logs: VBox.log

What's wrong in here?

Tried to de-active 3D acceleration?

Try different "Graphics Controller".
Mint 19.2 is which Ubuntu? 18.04?
So mybe this could cause the problem.

The 3D acceleration worked when I didn't have SSD enabled.
Now I disabled it and I still face the same issue.

Mint 19.2 is based on Ubuntu 18.04.2.

I tried to change the Graphics Controller from VBoxSVGA to VMSVGA and it surprisingly worked! :+1:
Hm... it doesn't say anything about it in the manual. I just followed it strictly and they recommend using VBoxSVGA, but for some reason, when you switch to SSD, you should change the Graphics Controller to VMSVGA in order to work properly. Go figure!

And that should be just fine

That is a coincidence - usually you let the host handle what type of disk it is. There should be no reason for the guest to handle specific disk types - unless very specific reasons I have yet to learn.

Yes - I know the option exist - but haven't seen any viable reason for selecting it.

I just realized VBoxSVGA and VMSVGA don't have the same behavior. When I maximize the window, the resolution within doesn't adjust for VMSVGA, it just remains the same regardless of the window size. :thinking:

@linux-aarhus: I did let the host handle type of disk and did not play with it form the guest side. Is there any way I could have my VBoxSVGA to work properly?

That is why the guide recommends VBoxSVGA.

Install the package virtualbox-guest-iso - that is if not already did so.

I understand you are using an Ubuntu guest - so insert the ISO in the virtual rom drive - and on the guest run the installer from the ISO.

There is a section on Other Linux guests (section 7) in this topic.

As far as I understand a guest OS can not trigger a trim on the underlying ssd of the host system. This is because virtualbox guest is not writing directly to the HW. There is a layer in between. The virtualbox guest sees a HDD/SSD but this is in fact just a regular file on the host.

1 Like

Basically, are you suggesting I don't need an SSD flag for my Guest Mint installation?

That is correct.

The only reason I can think of - where the setting may be applicable - is when you are using raw disk access in the virtual machine.

I found this mention on superuser

Thanks, it brought me back the original/recommended Graphics Controller and it clarifies that NOT selecting the SSD doesn't influence the actual performance of my Guest OS.

I do not know what this flag is good for.

@linux-aarhus: The following accepted answer was written back in 2011:

This will only matter if you have a solid-state drive on the host computer and have the virtual hard drive on the same drive.

From the guest OS's perspective, all it will do is disable disk defragging, and try to send TRIM commands to the drive.

I do have an SSD and virtual hard drive on the same drive. In comments right below it I also found this (comment from 2013):

The original question was asking about turning this feature on while running the virtual machine off of a hard drive, not a solid state drive. Indeed it is worth turning this feature on if the image resides on a SSD.

Any comments? :thinking:

I have never enabled this feature - just edit your guest fstab to use the noatime mount option - this limits the number of times the file allocation table changes.

If you were to run virtual machines on a host with GUI and maybe even raw disk - I think the option may be useful - but otherwise not.

In your case it even seems to create issues for the guest.

SSDs and kernel has come a long way since 2013 - we are talking 6 years - which is quantum leaps in terms of technology.

The Arch wiki mentions that the discard option is not necessary on a host with SSD or NVMe (advanced SSD) and recommends enabling the fstrim.timer which will schedule a weekly trim of the SSD.

But I will leave entirely up to your judgment - we - your fellow users - cannot make any decisions on your behalf.

That said - in my useless opinion - you don't need that ssd flag because the virtual disk is only a file - handled by the host.

While writing this - I could think of cases where the guest OS and thus the host disk might benefit from the guest OS signaling back to the device that a certain file is deleted - inside the guest - and thus not needed - e.g. the host can mark the disk space as deleted and reclaim through fstrim - this could be beneficial for long term virtual machines - and a lot of virtual machines are long term - just not on my system - that particular flag could have some benefits unknown at time of writing. 2019-11-12T14:49:00Z

So - if I could rephrase all those speculations - into one sentence - it would be

  • If your virtual machine are long term
    • not just tests but for real long term usage
    • enable the SSD option.

Thanks, that was very in-depth and accurate. It gave me a great overview of what's going on.

Luckily, I will not use this particular virtual machine as long term.
Unfortunately, I am still clueless on how to make a peace between SSD and VBoxSVGA in case I will need to build a long term VM.

Well - I would say - test - experiment - after all - it is only virtual :slight_smile: - half the fun is the process - at least in my case :nerd_face:

1 Like

Speaking of fun... steps I reproduced:

  1. Turned off Mint.
  2. Switched back to SBoxSVGA.
  3. Booted Guest Mint.
    Works fine!

Suddenly I have a working SSD + SBoxSVGA for the very first time, without changing anything. :laughing:
Which again - reminds me on...


It may be significant that from a non-working SSD+SBoxSVGA I switched to VMSVGA first and then back to SBoxSVGA, which then - worked.

1 Like

It could be something completely unrelated to SSD, might be a coincidence - I just rebooted my guest Mint and faced the original issue again. Then I shut it down and booted it again (without changing settings) - no issues! Seems like a weird bug in Virtualbox.

1 Like

Maybe you can report this strange behavior:


Would be good if solved in 6.1 and 6.0.x

1 Like

This could be related, but let's check... on my guest:

$ sudo apt install build-essential dkms linux-headers-$(uname -r)
$ sudo systemctl enable --now vboxservice
Failed to enable unit: Unit file vboxservice.service does not exist.

According to the manual:

Enable the vboxservice - required for screen sizes and shared folders

Is vboxservice still required on guest, or is it an outdated part of the manual? I installed the Guest Additions ISO, I can successfully share folders and clipboards bidirectional. The only thing I couldn't fix is this issue on guest. If it's really required it may have caused flickering in my guest. Any ideas?

For all the people from the future who might come here for a resolution of their own issue, I reported the same bug to the Virtualbox community, so you can continue to track it here:


1 Like

Forum kindly sponsored by