Announcement

Collapse
No announcement yet.

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

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #51
    Originally posted by Takla View Post
    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?

    Originally posted by Quackdoc View Post

    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.

    Comment


    • #52
      Originally posted by dalingrin View Post
      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

      Comment


      • #53
        Originally posted by dalingrin View Post

        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.





        Comment


        • #54
          Originally posted by Quackdoc View Post
          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.

          Comment


          • #55
            Originally posted by arQon View Post

            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

            Comment


            • #56
              Originally posted by Quackdoc View Post
              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.

              Comment


              • #57
                Originally posted by arQon View Post

                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.

                Comment

                Working...
                X