Linux KVM Continues Offering Much Better Performance Than VirtualBox

[varikonniemi]

Impressive performance for KVM, a shame getting it up and running is so hard.

[andoride]

Is also possible to increase KVM performance using static cpu "pinning" for avoiding overhead on context switching in the host and also hugemem should help.
I think VirtualBox is great because is easy to use and also tools like vagrant use VirtualBox as default.

[andoride]

Impressive performance for KVM, a shame getting it up and running is so hard.

have you tried virt-manager?

[emblemparade]

I use both quite a lot, but as a developer doing a mix of frontend and backend work on various operating systems I tend to prefer VirtualBox due to so many ease-of-use-features: nice management GUI allowing easy connection/disconnection of USB and other devices, powerful guest additions with support for screen resizing and shared clipboards, automatically sets up remote access, etc. It's just really nice for everyday virtualization needs. Performance isn't always a high priority, depending on what you're doing.

I do wish the KVM/QEMU world would be able to match VirtualBox better feature to feature. Still, happy to have both.

BTW, as others have pointed out, VirtualBox uses KVM as hypervisor by default on Linux, so the title is a bit misleading. The comparison is specifically about the libvirt-packaged KVM/QEMU vs. VirtualBox.

Generally, Michael, you can do a better job at describing and explaining the setups for your benchmarks. Almost always you get questions in the comments about whether you used feature X or Y and why.

[tuxd3v]

have you tried virt-manager?

virt-manager it too easy, no fun with it..
If he want to learn...using the shell its the better way to learn the intrinsics of it..
After all its very easy, to use KVM..

[Hi-Angel]

have you tried virt-manager?

Have they fixed work with external drives? A few years ago when I tried it, running a VM whose image is physically located on a partition mounted at /mnt have caused confusing errors, and required some non-trivial setup, something about pools of storage memory. Ironically, running that same image from terminal with QEMU was a lot easier (well, given you knew the arguments needed).

[torsionbar28]

Have they fixed work with external drives? A few years ago when I tried it, running a VM whose image is physically located on a partition mounted at /mnt have caused confusing errors, and required some non-trivial setup, something about pools of storage memory. Ironically, running that same image from terminal with QEMU was a lot easier (well, given you knew the arguments needed).

I can't picture what you're talking about. To specify a new storage pool location in virt-manager, you simply go to Edit -> Connection Details -> Storage and hit the '+' icon to add a new filesystem path. It doesn't care whether the path is backed by USB, NFS, Firewire, SAS/SATA, etc.

[torsionbar28]

I wonder if the difference is as noticeable with a Windows guest. Unfortunately though there's no way I know of for getting desktop acceleration with qemu/KVM for D3D.

Audio is also a sore spot in qemu/kvm. IMO a general rule of thumb, is that for Linux guests, qemu/kvm is the obvious choice as it's very easy and straightforward to get going. But for Windows Desktop guests, Virtualbox offers a smoother simpler experience.

[BenInCOSprings]

Have they fixed work with external drives? A few years ago when I tried it, running a VM whose image is physically located on a partition mounted at /mnt have caused confusing errors, and required some non-trivial setup, something about pools of storage memory. Ironically, running that same image from terminal with QEMU was a lot easier (well, given you knew the arguments needed).

I had an issue like that a few days ago w/ version 2.11.1 (Ubuntu 18.04 version). I wanted to move all my images from one HD to another, so I tried to make a symlink from the default location on the old HD (/var/lib/libvirt/images) to the new HD, to which I had copied the image files. When I tried to launch VM's, it errored out with "could not open disk image"... " "Permission denied". I made sure permissions on the symlink, folders, and files were the same as before, did multiple service restarts and even reboots, but to no avail. What eventually fixed it was removing the disk from a *single* VM and then re-adding it. That fixed whatever the issue was for *all* VM's.

[GreenByte]

Have they fixed work with external drives? A few years ago when I tried it, running a VM whose image is physically located on a partition mounted at /mnt have caused confusing errors, and required some non-trivial setup, something about pools of storage memory. Ironically, running that same image from terminal with QEMU was a lot easier (well, given you knew the arguments needed).

My VM OS images are all on a NAS so I suppose they have it all sorted out by now.