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.
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 - half the fun is the process - at least in my case
Speaking of fun... steps I reproduced:
- Turned off Mint.
- Switched back to SBoxSVGA.
- Booted Guest Mint.
Suddenly I have a working SSD + SBoxSVGA for the very first time, without changing anything.
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.
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.
Maybe you can report this strange behavior:
Would be good if solved in 6.1 and 6.0.x
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:
Turns out this is completely wrong. According to maintainers of Virtualbox,
VBoxSVGA is meant for Windows Guests only. The default for Linux Guests should be always
That may be true for some for some distributions - but for Manjaro you should use VBoxSVGA if you want the vm to resize correctly.
And the VBoxSVGA has no correlation with the SSD flag so your reply is not the answer.
If you use VMSVGA for a Manjaro client - your resizing will not work - you will be able to manually size the vm by selecting a screen resolution inside the vm - but the vm adapting to a size change using VMSVGA - has not been working for a long time on Manjaro.
The title had a questionmark at the end, which means it was just my assumption. Since now I know there is no correlation between SSD flag and VBoxSVGA, I changed my title and accepted an answer to select VMSVGA as the default Display Controller to avoid my original issue, which was a display issue. It's more important to actually see the content of my Linux Guest, than to be able to resize the window and not see anything.
Thanks! It seems like just another typical example of dealing with open-source: one solution will give you feature A, but you lose B and the other will give you B and C, but you can't have A.
Well - thanks for the feedback.
I have looked at the mentioned post - and I am a little mystified as to why one display driver should not be for other than Windows.
A Manjaro guest works best with the VBoxSVGA - but it appears that a Ubuntu guest likes the VMSVGA driver.
I think we can be more clear on the topic of other guests than Manjaro - but as the general purpose of wiki and forum is Manjaro - then it should be obvious that the instructions for a VirtualBox VM is with Manjaro - not Ubuntu nor any other distribution.
I am puzzled about the same thing. This seems like an extremely important information that should be highlighted during the installation of Virtualbox Guests, but as you say - this is a forum related to issues with Manjaro.
I have modified the section on Display in the guide
P.S. As you may have noticed, I tried to dig this several times in my communication with the maintainer of Virtualbox, but he seemed quite irritated and not in the mood for getting into too much details.
The original manual is here, but I couldn't find an answer to that either:
This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.