VirtualBox 6.0 provides a new setting called Graphics Controller. There are four options to choose from:

  • None
  • VBoxVGA
  • VBoxSVGA

In the user manual I have found this information:

Graphics Controller: Specifies the graphics adapter type used by the guest VM. Note that you must install the Guest Additions on the guest VM to specify the VBoxSVGA or VMSVGA graphics controller. The following options are available:
– VBoxSVGA: The default graphics controller for new VMs that use Linux or Windows 7 or later. This graphics controller improves performance and 3D support when compared to the legacy VBoxVGA option.
– VBoxVGA: Use this graphics controller for legacy guest OSes. This is the default graphics controller for Windows versions before Windows 7.
– VMSVGA: Use this graphics controller to emulate a VMware SVGA graphics device.
– None: Does not emulate a graphics adapter type.

But still it does not describe which of them and why should I prefer.
When should I choose None?
Is VMSVGA better than VBoxSVGA?
What is wrong with VBoxVGA?

I have tested booting of archlinux-2019.02.01-x86_64.iso with virtualbox 6.0.4 in efi and legacy modes:

│ Adapter  │            EFI mode             │ Legacy mode │
│ VBoxVGA  │ ok                              │ ok          │
│ VMSVGA   │ ok in systemd-boot menu,        │ ok          │
│          │ then black screen for some time │             │
│          │ when booting, then becomes ok   │             │
│ VBoxSVGA │ black screen                    │ ok          │

Also I have noticed that with VMSVGA and VBoxSVGA passing video=XRESxYRES parameter is ignored:

| Adapter  |    EFI mode    | Legacy mode  |
| VBoxVGA  | works          | works        |
| VMSVGA   | doesn't work   | doesn't work |
| VBoxSVGA | could not test | doesn't work |

But it is still possible to set some of that ignored resolutions after boot with fbset.

  • I would not recommend using EFI in a virtual machine unless you absolutely need to. It is useless overhead.
    – Bachsau
    Mar 28, 2019 at 0:52
  • 2
    I tested all three of them on my CentOS 7 vm with the i3 window manager running on it using a 4k monitor. VBoxSVGA seems to slightly win over VMSVGA. VBoxVGA was terrible. None of the three work well on my 2018 MacBook Pro's retina display. There is so much lag that is almost unusable.
    – Shadoninja
    Feb 21, 2020 at 20:09
  • @Shadoninja im getting back into linux and I installed debian today in virtualbox. nothing worked graphics wise so slow and everything. im trying VBoxSVGA at least it shows as VBX in gnome display settings. I'm also on a MacBook Pro Mid 2018 this comment seems to have helped so far Thanks
    – Big Joe
    Sep 18, 2021 at 6:12

7 Answers 7


Based on what I've found in the source code:


This emulates a graphics adapter specific to VirtualBox, the same as in previous versions (<6.0.0).

  • This is the default for images created for previous versions of VirtualBox (<6.0.0) and for Windows guests before Windows 7.
  • It has some form of 3D passthrough, but – if I remember correctly – uses an insecure approach that just lets the guest dump any and all commands to the host GPU.
  • Using it on a Linux guest requires installing the guest additions because this adapter is not (yet) supported by the mainline Linux kernel.
  • Only supports OpenGL 1.1 on 64bit Windows 10 and all Linux guests.

This option likely exists just to provide continuity – after upgrading to 6.0, all old VMs have this mode selected automatically so there's no unexpected change in behavior; you don't lose whatever acceleration you previously had.


This emulates the VMware Workstation graphics adapter with the "VMware SVGA 3D" acceleration method.

  • Contrary to what the manual says, this is currently the default for Linux guests.
  • It is supposed to provide better performance and security than the old method.
  • This is supported by the mainline Linux kernel using the SVGA driver.
  • Supports OpenGL 2.1 on all Windows and Linux guests.
  • It might also have the advantage of supporting old operating systems which had VMware guest additions available but not VirtualBox guest additions. (I plan to test this with Windows 9x, which is otherwise a massive pain to get even VESA graphics working with VirtualBox)


This provides a hybrid device that works like VMSVGA (including its new 3D acceleration capabilities), but reports the same old PCI VID:PID as VBoxVGA.

  • This is the default for Windows guests.
  • The advantage of this mode is that you can upgrade existing VMs (which previously used VBoxVGA and had the VirtualBox Video driver installed) and they don't lose their graphics in the process – they still see the same device, until you upgrade the "guest additions" at any later time to enable 3D acceleration.
  • Also, because it's still VMware SVGA emulated by VirtualBox, choosing this option and using the VirtualBox driver may still have advantages over the VMware one, e.g. allow to make use of VirtualBox-specific additional features.


This is, obviously, no emulated graphics at all. Only use it if you provide a real GPU via PCI passthrough, or if your system absolutely doesn't need a GPU.


  • 2
    <virtualbox.org/browser/vbox/trunk/src/VBox/Devices/Graphics/…>; note how both VBoxSVGA and VMSVGA result in VMSVGAEnabled=true and VMSVGA3dEnabled=${3DEnabled}, with the only difference between them being VMSVGAPciId. Feb 8, 2019 at 5:40
  • 2
    @galgaesh VBoxVGA is supported by drivers/staging/vboxvideo as of approximately Linux 4.14. Feb 15, 2019 at 15:12
  • In other words, VBoxVGA is better for running hardware GPU accelerated non-graphics operations also? oclvanitygen? "approach that just lets the guest dump any and all commands to the host GPU."
    – Willtech
    Mar 18, 2019 at 9:22
  • 2
    @Willtech: Apparently no; it still has a translator of some sort. I was previously under the impression that it didn't, but it couldn't actually be that way, since it'd just corrupt the host screen contents as soon as it tried to draw anything. Mar 18, 2019 at 10:20
  • 1
    I don't know if it's specific to my OS (BionicPup 6.0) but I find that I run into problems with elements not being drawn when using VMSVGA mode, as well as no drawing at all when in text mode. (I had thought it might be useful for faster rendering, since the Guest Additions won't install the VBoxVGA graphics driver, even when everything compiles correctly.) And apps that previously would work no longer can start.
    – trlkly
    Jul 25, 2019 at 7:26

But they do tell you quite explicitly when you should prefer them:

– VBoxSVGA: The default graphics controller for new VMs that use Linux or Windows 7 or later. This graphics controller improves performance and 3D support when compared to the legacy VBoxVGA option.

  • Linux or Windows >7
  • improves performance and 3D support

– VBoxVGA: Use this graphics controller for legacy guest OSes. This is the default graphics controller for Windows versions before Windows 7. 

  • (by inference) slightly lower performance but more compatibility with older OSes
  • Old OS or Windows < 7

– VMSVGA: Use this graphics controller to emulate a VMware SVGA graphics device. 

  • Emulates a VMWare device
  • probably best when your VM was originally set up on VMWare and has their tools installed
  • may not be as fast as VBox cards because it's trying to be compatible with something else.

– None: Does not emulate a graphics adapter type.

  • you don't want a graphics adapter
    i.e. you want to run the machine headless or over SSH and don't need the overhead of it emulating graphics.
  • could improve performance as it removes a layer or emulation

Performance is one difference. Testing with glxgears, I get:

  • VBoxVGA: 60fps +/- 2 (very low, but moving a window around is not smooth so it seems plausible)
  • VMSVGA: 1570fps +/- 50 (after a reboot, I get 1300fps +/- 200?!)
  • VBoxSVGA: 970fps +/- 30 (in this mode, Cinnamon warns me that the desktop environment's graphics are running on CPU)

The guest additions were already updated from the Debian repositories before it spawned the VBoxVGA deprecation warning the first time, so I could just switch it without needing to update first. Check your version using dpkg -l | grep virtualbox.

Guest additions are version 6.0.4, mesa-utils (containing glxgears) 8.4.0-1+b1, base OS is Debian 10 (Buster) with Cinnamon.

VM has PAE/NX enabled, 3D acceleration but no 2D acceleration, 2 CPUs assigned (the host has 2 cores with 2 threads each), PV default, VT-x/AMD-V enabled, and nested paging.

  • my host is centos7, VM is centos7 with cinnamon... but unfortunately my cinnamon still reports software rendering and i can feel the UI lag. maybe i'll try using VBoxSVGA instead of VMSVGA. Dec 16, 2020 at 18:30
  • 3
    It depends much on the host and guest system I guess. I run VirtualBox 6.1.18 on a Windows 10 i3 3rd Gen Probook and on Debian Buster guest with LXDE, glxgears show ~600 fps with VBoxVGA without 3D acceleration enabled, VMSVGA only ~500 fps. When enabling 3d acceleration, which is not really supported by that HD Graphics 4000, both become much slower, ~190 and ~170 fps, VBoxVGA still being faster. All tested with xserver-xorg-video-vmware display driver btw, which is strangely used for the VBoxVGA adapter as well. So if performance matters for what one does on a VM display, test yourself.
    – MichaIng
    Mar 9, 2021 at 18:32

I was able to auto set the resolution of the guest with wayland compositor only using VBoxSVGA. virtualbox-guest-additions couldn't auto-resize guest display with wayland when using VMSVGA.

  • I did not get guest auto-resizing with VMSVGA and xUbuntu 18.04 as well and VBoxSVGA works (but only after log in to xfce) Jan 18, 2020 at 11:10

VBoxSVGA doesn't recognize the CustomVideoMode1 [1] settings, only VMSVGA recognizes and applies them.

This might be an issue with wayland & swayvm, who knows; couldn't figure out a better solution.

[1] https://www.virtualbox.org/manual/ch09.html#customvesa


VBoxVGA remembers and restores Windows guest window size adjustments. VBoxSVGA DOES NOT remember size adjustments.

I want my Windows guests to open with a display size of 1240x712. If I use VBoxSVGA, the guests always open at 1024x768 and then I need to resize them.

If I use VBoxVGA, the display is saved/restored, the hosts open at 1240x712 without further adjustment.

In fact, if the "Adjust window size" setting is used to change the display, shutting down the Windows guest and snapshotting will preserve the new setting. The VBoxSVGA ignores the running size changes.

  • This sounds slightly like an out-of-date "Guest Additions" package... Mar 13, 2020 at 19:53

I had a similar problem on Fedora 31. You might have to go to "Settings > Devices > Display > Resolution" and select your resolution manually. Once you have installed Guest Additions correctly, your host's resolution will be on the list of supported resolutions for the guest.

On Ubuntu, that would be

  1. Open the Activities overview and start typing Displays.

  2. Click Displays to open the panel.

  3. If you have multiple displays and they are not mirrored, you can have different settings on each display. Select a display in the preview area.

  4. Select the resolution or scale, and choose the orientation.

  5. Click Apply. The new settings will be applied for 20 seconds before reverting back. That way, if you cannot see anything with the new settings, your old settings will be automatically restored. If you are happy with the new settings, click Keep Changes.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .