Announcement

Collapse
No announcement yet.

VirtualBox Is Still Running Slower Than QEMU-KVM

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

  • VirtualBox Is Still Running Slower Than QEMU-KVM

    Phoronix: VirtualBox Is Still Running Slower Than QEMU-KVM

    Recently I ran some benchmarks looking at the performance of the Ubuntu 14.04 LTS development code and from there I tested the bare metal system, the same system with a Linux KVM instance of Ubuntu 14.04 itself, and then afterwards another VM with the same settings and software but using Oracle VM VirtualBox. Here are those early Ubuntu 14.04 Linux virtualization benchmarks.

    http://www.phoronix.com/vr.php?view=19551

  • #2
    You should pass "-cpu host" to qemu so that it passes-through the processor identifier and flags

    Comment


    • #3
      Any graphics benchmarks? QEMU-KVM graphics performance sucks.

      Comment


      • #4
        Originally posted by wargames View Post
        Any graphics benchmarks? QEMU-KVM graphics performance sucks.
        Not if you use VGA passthrough.

        Comment


        • #5
          Originally posted by GreatEmerald View Post
          Not if you use VGA passthrough.
          VGA passthrough requires an additional graphics adapter, not everyone has that and not everyone wants to use separate cards for bare metal and the VM.

          Comment


          • #6
            Originally posted by wargames View Post
            Any graphics benchmarks? QEMU-KVM graphics performance sucks.
            With QXL things are much smoother (2D). With Windows guests I usually prefer RDP (2D). Both are excellent under QEMU-KVM.

            Comment


            • #7
              Originally posted by Calinou View Post
              VGA passthrough requires an additional graphics adapter, not everyone has that and not everyone wants to use separate cards for bare metal and the VM.
              Yes, but it is an option, and it's one that is available in QEMU-KVM and not available in VirtualBox.

              Comment


              • #8
                Originally posted by GreatEmerald View Post
                Yes, but it is an option, and it's one that is available in QEMU-KVM and not available in VirtualBox.
                Do you know if it is possible to use the integrated (motherboard/APU) graphics for the host and a dedicated graphics card for the guest?

                Comment


                • #9
                  Originally posted by wargames View Post
                  Do you know if it is possible to use the integrated (motherboard/APU) graphics for the host and a dedicated graphics card for the guest?
                  You can in some cases (I think, Intel only, on AMD, the IGP is disabled if a dedicated card is plugged).

                  Comment


                  • #10
                    I used virtualbox in the past until i starrted to build my kernels and find that it didnt work with the latest ones (around 3.8 or something).
                    So i replaced it with qemu (i use libvirt+virtmanager for ease of management), converted my hdd images to raw then the VMs. This libvirt thingie is mightily handy, you can supervize your VMs that run in separated processes independent from X + you can connect to the supervizor via ssh, tunnel spice connections to it (inluding the attaching of REMOTE usb devices), a feature that virtualbox lacked.
                    Linux guests are like fish in the water with qemu/kvm since the virtio drivers are built in the kernel, absolutely no intervention required.
                    For Windows guests you just have to go to http://www.spice-space.org/download.html , download+install the windows guest tools, reboot and you will have all virtio+qxl drivers installed along with the vdagent (that passes through clipboard, seamless mouse and USB redirection).

                    Note - for optimal operation, you have to use the virtio devices (virtual network card and virtual hdd controller), qxl virtual video device, spice connection and set up a spice channel for USB redirection.

                    All in all using this setup (=qemo/kvm + libvirt/virt-manager) greatly reduced management related issues and introduced previously lacking full remote control features. What was lost is some 3d support in Windows guests (doesnt really bother me since i dont need it).
                    Performance wise qemu/kvm seems to perform just like vbox, never bothered with specifics as long as it doesnt hog my computer needlessly when idle.

                    Originally posted by Calinou View Post
                    You can in some cases (I think, Intel only, on AMD, the IGP is disabled if a dedicated card is plugged).
                    I have an AMD integrated (A8-5500/A8-6500) and i played around a bit with vga pass through and i could attach the dedicated card (i had some old cards laying around) to the VM, install the driver but it couldnt initialize in the guest. I didnt pursue this farther and maybe the issue was that at that time i used fglrx (someone said that fglrx doesnt play nice here). BTW you have to use a mobo that supports iommu for this AFAIK which usually is available in certain higher(ish) end chipsets and mobos.

                    Comment


                    • #11
                      I wonder how the benchmarks would be affected by lowering the number of virtual cores assigned to the VMs. At least with VMware products, especially hosted ones, it's often recommended to never set the number of virtual cores equal to or more than the number of physical cores (ie. not counting hyper-threading logical cores). Some (many?) workloads supposedly get better performance by doing this.

                      Comment


                      • #12
                        >>HPC Challenge wouldn't build under QEMU-KVM since the reported CPU string was unrecognized as "QEMU Virtual 1.7.0"

                        Just use -cpu host as cpu model. If not, you don't use most cpu features (sse2,ss3,...). It should give you a big difference if benchmark use theses cpu features.



                        (It could be great to have the full qemu command detail, to see which options are used for cpu, disks,....)

                        Comment


                        • #13
                          Originally posted by vick View Post
                          I wonder how the benchmarks would be affected by lowering the number of virtual cores assigned to the VMs. At least with VMware products, especially hosted ones, it's often recommended to never set the number of virtual cores equal to or more than the number of physical cores (ie. not counting hyper-threading logical cores). Some (many?) workloads supposedly get better performance by doing this.
                          Leaving one core unassigned means it can be dedicated to the host, and if the guest decides to eat all your resources, you will still be able to stop the machine instead of doing a hard reboot. I think that lowers the performance of the guest, but gives you more reliability and more performance for the host.

                          Comment


                          • #14
                            Originally posted by GreatEmerald View Post
                            Leaving one core unassigned means it can be dedicated to the host, and if the guest decides to eat all your resources, you will still be able to stop the machine instead of doing a hard reboot. I think that lowers the performance of the guest, but gives you more reliability and more performance for the host.
                            Have you had that happen? Qemu "cores" are simply threads to the host, and the host can distribute them as it wills.

                            Comment


                            • #15
                              Originally posted by curaga View Post
                              Have you had that happen? Qemu "cores" are simply threads to the host, and the host can distribute them as it wills.
                              Yes, I had it happen, but on VirtualBox (I don't use QEMU much).

                              Comment

                              Working...
                              X