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

[dalingrin]

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.....

What does Virtualbox do to help RDP that isn't native to Windows?

qemu can likely do both since you have intel UHD.

There isn't a good way to do a virtual GPU with Windows and QEMU that I know of.

[Quackdoc]

There isn't a good way to do a virtual GPU with Windows and QEMU that I know of.

you would use intel GVT-G or SRIOV depending on what gpu. I think that would likely be gvtg

[Takla]

What does Virtualbox do to help RDP that isn't native to Windows?

https://www.virtualbox.org/manual/ch07.html

Oracle VM VirtualBox can display virtual machines remotely, meaning that a virtual machine can execute on one computer even though the machine will be displayed on a second computer, and the machine will be controlled from there as well, as if the virtual machine was running on that second computer.

For maximum flexibility, Oracle VM VirtualBox implements remote machine display through a generic extension interface called the VirtualBox Remote Desktop Extension (VRDE). The base open source Oracle VM VirtualBox package only provides this interface, while implementations can be supplied by third parties with Oracle VM VirtualBox extension packages, which must be installed separately from the base package. See Section 1.5, “Installing Oracle VM VirtualBox and Extension Packs”.

Oracle provides support for the VirtualBox Remote Display Protocol (VRDP) in such an Oracle VM VirtualBox extension package.

VRDP is a backwards-compatible extension to Microsoft's Remote Desktop Protocol (RDP). As a result, you can use any standard RDP client to control the remote VM.

It works extremely well.

[arQon]

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

Then I have no idea what your problem is, sorry. You seems happy where you are anyway though, at least.

Regardless, I think we've established the main point, which is that provided you have VTx HW every hypervisor has equivalent performance to within margin of error for pretty much every non-GUI task. I don't think that's really a surprise to anyone.

[Quackdoc]

Then I have no idea what your problem is, sorry. You seems happy where you are anyway though, at least.

Regardless, I think we've established the main point, which is that provided you have VTx HW every hypervisor has equivalent performance to within margin of error for pretty much every non-GUI task. I don't think that's really a surprise to anyone.

not really, I tried my best to even the playing field a tad bit, so on qemu I used IDE hdd controler for an fedora iso, and for graphics and QXL instead of virtio since I have to admit im not sure how much overhead they may or may not have on vbox. both running 4 cores at 4gb of ram changed resolution to 1080p on each as well. I did some graphics testing using llvmpipe since it does a pretty good job and burning cpus. and it's something I could do pretty quickly double checked that vbox was runing with vtx by attempting to run qemu while vbox was running. and expectedly it didn't launch.

and while it does seem some workloads are within margin of error, some aren't. and vbox even won in sysbench

glxgears - qemu
vbox 400-500fps
qemu 750-800fps

glmark2 - qemu
vbox score 128
qemu score 145

sysbench cpu --threads=4 run - vbox
vbox speed:6408.38, total-time:10.0005 , events:64719 latency-sum:39968.48
qemu speed:6206.10 , total-time:10.0005 , events:62072 latency-sum:39973.69

7za b -mmt1
vbox avg 99, 3061, 3025, 99, 3244, 3208
qemu avg 96, 3630, 3491, 96, 3568, 3427

it's probably not worth mentioning, but qemu did personally feel more responsive overall but that could be placebo bias. but anyways I don't think this is exactly margin of error. though I suppose I could have tested with fifo scheduling to help possibly alieviate any external factors...

but I wouldn't consider this margin of error. either

[arQon]

but I wouldn't consider this margin of error. either

I have no idea how llvmpipe behaves, but I'd be leery of anything involving presentation, because that alone takes you into "graphics" territority, which I think everyone acknowledges vbox is far from good at. (It's perfectly adequate for a DE etc, and in fact I find it also adequate for fullscreen video, but it certainly works the CPU a lot more than it "should").

The sysbench numbers are a wash, I'd say: 3% is pretty close to run variance for most workloads these days.

The 7z numbers are interesting, and as you say, different enough to likely be indicative of something real. They're also rather puzzling in light of the sysbench results, since I wouldn't expect 7z to be incurring much in the way HV roundtrips: it's pretty much all just repeatedly churning through memory.

The implication is that vbox is actually handling syscalls etc *better* than qemu, but something in its memory handling is poor. I'll ponder, thanks.

[Quackdoc]

I have no idea how llvmpipe behaves, but I'd be leery of anything involving presentation, because that alone takes you into "graphics" territority, which I think everyone acknowledges vbox is far from good at. (It's perfectly adequate for a DE etc, and in fact I find it also adequate for fullscreen video, but it certainly works the CPU a lot more than it "should").

The sysbench numbers are a wash, I'd say: 3% is pretty close to run variance for most workloads these days.

The 7z numbers are interesting, and as you say, different enough to likely be indicative of something real. They're also rather puzzling in light of the sysbench results, since I wouldn't expect 7z to be incurring much in the way HV roundtrips: it's pretty much all just repeatedly churning through memory.

The implication is that vbox is actually handling syscalls etc *better* than qemu, but something in its memory handling is poor. I'll ponder, thanks.

llvmpipe shouldn't be effected by gpu at all, but if you really wanted to, you could run it without any display whatsoever buy using a headless mutter session. then it would be totally isolated from any display whatsoever.