Ubuntu 22.04 LTS Disables 3D Acceleration For Guest VMs With GNOME Boxes / Virt-Manager

[Operius73]

Experimental stuff shouldn't be in a LTS release anyway.

[Quackdoc]

100% this. Even if documentation is not read by everyone, very often as part of writing documentation, bugs are uncovered.

I personally have never had an issue with qemu's documentation. very seldom do I find something code diving that isn't in the docs, or in the help arguments. now formatting could be better, but oh well. invocation page will cover majority of people use anyway

[F.Ultra]

I understand the confustion, but no. this is enlightenments givent to the guest. VBOX's dogcrap naming scheme you can see here. https://www.virtualbox.org/manual/ch...l#gimproviders

Yes that is so a guest that needs e.g the KVM interface for performance reasons can utilize this when running under VirtualBox. Am I understanding you correctly in that you want VirtualBox to use KVM as the host hypervisor instead of their own?? I can see no benefits from going that route.

[F.Ultra]

i'd love to see those numbers. vbox is always far worse for me personally. the fact that it can't use kvm is a big blow to vbox preformance.

Quick unscientific test with a cpu bound task (openssl speed -evp aes-256-cbc -elapsed):

Host:

OpenSSL 1.0.2g 1 Mar 2016
built on: reproducible build, date unspecified
options:bn(64,64) rc4(8x,int) des(idx,cisc,16,int) aes(partial) blowfish(idx)
compiler: cc -I. -I.. -I../include -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -m64 -DL_ENDIAN -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -Wl,-Bsymbolic-functions -Wl,-z,relro -Wa,--noexecstack -Wall -DMD32_REG_T=int -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM -DECP_NISTZ256_ASM
The 'numbers' are in 1000s of bytes per second processed.
type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes
aes-256-cbc 866300.86k 963646.02k 991204.18k 998266.54k 1000303.27k
aes-256-cbc 878229.70k 966335.30k 991664.30k 996231.17k 998836.91k
aes-256-cbc 879451.59k 967226.26k 991830.27k 998059.01k 999890.94k
aes-256-cbc 865587.17k 963469.40k 990983.85k 997626.20k 998793.22k

Guest:

OpenSSL 1.0.2g 1 Mar 2016
built on: reproducible build, date unspecified
options:bn(64,64) rc4(8x,int) des(idx,cisc,16,int) aes(partial) blowfish(idx)
compiler: cc -I. -I.. -I../include -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -m64 -DL_ENDIAN -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -Wl,-Bsymbolic-functions -Wl,-z,relro -Wa,--noexecstack -Wall -DMD32_REG_T=int -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM -DECP_NISTZ256_ASM
The 'numbers' are in 1000s of bytes per second processed.
type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes
aes-256-cbc 848130.07k 948853.89k 968278.87k 987369.13k 980533.25k
aes-256-cbc 849827.22k 941274.69k 980202.50k 982381.23k 978777.43k
aes-256-cbc 738599.86k 913556.39k 933387.06k 940546.72k 943909.55k
aes-256-cbc 841357.00k 934911.45k 960774.74k 969337.17k 968269.82k

So yes, cpu-bound tasks are close to native speed in VirtualBox. Looking at just the 16-bytes case the average performance is 94% of that of the native, and for the 8192-bytes case the average performance is 97% of that of the native.

[Quackdoc]

Yes that is so a guest that needs e.g the KVM interface for performance reasons can utilize this when running under VirtualBox. Am I understanding you correctly in that you want VirtualBox to use KVM as the host hypervisor instead of their own?? I can see no benefits from going that route.

preformance. when using optimizations they can eek out a bit more preformance. but it still pales in comparison to use KVM or XEN for acceleration in my experience.

[Quackdoc]

Quick unscientific test with a cpu bound task (openssl speed -evp aes-256-cbc -elapsed):

Host:

OpenSSL 1.0.2g 1 Mar 2016
built on: reproducible build, date unspecified
options:bn(64,64) rc4(8x,int) des(idx,cisc,16,int) aes(partial) blowfish(idx)
compiler: cc -I. -I.. -I../include -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -m64 -DL_ENDIAN -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -Wl,-Bsymbolic-functions -Wl,-z,relro -Wa,--noexecstack -Wall -DMD32_REG_T=int -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM -DECP_NISTZ256_ASM
The 'numbers' are in 1000s of bytes per second processed.
type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes
aes-256-cbc 866300.86k 963646.02k 991204.18k 998266.54k 1000303.27k
aes-256-cbc 878229.70k 966335.30k 991664.30k 996231.17k 998836.91k
aes-256-cbc 879451.59k 967226.26k 991830.27k 998059.01k 999890.94k
aes-256-cbc 865587.17k 963469.40k 990983.85k 997626.20k 998793.22k

Guest:

OpenSSL 1.0.2g 1 Mar 2016
built on: reproducible build, date unspecified
options:bn(64,64) rc4(8x,int) des(idx,cisc,16,int) aes(partial) blowfish(idx)
compiler: cc -I. -I.. -I../include -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -m64 -DL_ENDIAN -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -Wl,-Bsymbolic-functions -Wl,-z,relro -Wa,--noexecstack -Wall -DMD32_REG_T=int -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM -DECP_NISTZ256_ASM
The 'numbers' are in 1000s of bytes per second processed.
type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes
aes-256-cbc 848130.07k 948853.89k 968278.87k 987369.13k 980533.25k
aes-256-cbc 849827.22k 941274.69k 980202.50k 982381.23k 978777.43k
aes-256-cbc 738599.86k 913556.39k 933387.06k 940546.72k 943909.55k
aes-256-cbc 841357.00k 934911.45k 960774.74k 969337.17k 968269.82k

So yes, cpu-bound tasks are close to native speed in VirtualBox.

interesting, all my cpu computer work loads work quite a bit faster in qemu.

[F.Ultra]

preformance. when using optimizations they can eek out a bit more preformance. but it still pales in comparison to use KVM or XEN for acceleration in my experience.

Acceleration of what? Both KVM and VirtualBox uses Intel VT and AMD-V as the hypervisor for the cpu so they should be close to 100% identical for cpu bound tasks. XEN went a different route (which is why KVM was so much faster than XEN when KVM came out) but if I'm not mistaken XEN have since moved over to also use Intel VT and AMD-V (but I could be wrong here since I have not worked with XEN in a very long time).

[Takla]

I use VirtualBox (VBoxHeadless) to run a Win 7 VM on my very ancient Proliant N40L microserver, running Debian Stable on AMD Turion II. It's fine. It uses the CPU's virtualisation capabilities and, really importantly for me, virtualbox does an excellent implementation of RDP. It works so much better than VNC and lets me easily access the Win VM from Android using aFreeRDP and from Linux using Remmina. I used to access Win VMs via VNC but VB's excellent RDP responsiveness matters a lot when you're accessing your LAN via VPN over 4G and I'm pleased I switched. The people who expressed fanatical opinions...well, they're fanatics. Ignore them. I like KVM and Qemu. I use them on my desktop. And when they offer remote access as good as VB's RDP then I'll be happy to switch. Meanwhile.....

[arQon]

i'd love to see those numbers.

I already gave you them. And now someone else has too.

That makes this a "you" problem, but I think I can make a pretty good guess at it: you left KVM running, forcing VBox to use SW virt instead of VTx. Sound likely?

[Quackdoc]

I already gave you them. And now someone else has too.

That makes this a "you" problem, but I think I can make a pretty good guess at it: you left KVM running, forcing VBox to use SW virt instead of VTx. Sound likely?

nope, thats one of the things I re-check often when testing