Actually you can run virtualbox in a headless server using the VBoxManage and VBoxHeadless[1]. I have been using that for years.

[1]: http://www.virtualbox.org/manual/ch07.html

This is the correct answer. qemu --accelerator=kvm is the principal way KVM is used.

I think this is closest to the correct answer, so I will try to expand on it. Qemu, is a processor emulator[1] and can emulate processors like x86, x86_64, ppc, mips, arm etc. Qemu is usually run with kvm[2].

[1]: http://wiki.qemu.org/download/qemu-doc.html#Introduction

[2]: http://www.linux-kvm.org/page/Main_Page

How fast does it run as compared to on Raspberry Pi itself?

In addition to KVM use couradical points out, it's also used in the Bitblaze BAP tool's TEMU component[1], which does dynamic analysis (including taint tracking) over x86 programs and kernels.

[1] http://bitblaze.cs.berkeley.edu/temu.html

My installs are headless, no 3D accel or Unity needed.

As originally mentioned, the VBox kernel modules are of poor quality. You may or may not trigger an edge case in your daily use, with or without a desktop environment.

This also may happen if you have another virtualization driver installed (even kvm)

Arch. But I've also had virtualbox crash on Debian testing. It's a mess.

I personally had a terrible time using VirtualBox on a Lenovo T420 running Windows 7 x64 about 2 years ago. I was having frequent blue screens, so Lenovo sent out a tech to swap the motherboard. The issue persisted, and after some time, I noticed that it seemed to always occur when I had multiple VMs running. The problem went away when I migrated to VMware Workstation.

Anecdotally, I've had issues on OSX with VirtualBox, so much so that I switched to VMWare Fusion on Mac hosts...

VirtualBox is the only app I've ever seen kernel-panic OSX. Twice.

This is also bad information. Kernel taint is a bitmap that represents a number of things:

  - Proprietary software (non-gpl-compatible, as you say. ex: vmware)
  - Crap (drivers/staging)
  - Out-of-tree modules (virtualbox)
  - whether the kernel has hit a BUG already
  - ...
  - lots of stuff

VirtualBox taints the kernel because it is out-of-tree, not because it is GPL-incompatible. Why is a GPL compatible kernel module(s) not merged yet?

Because the code quality is crap.

VBox was explicitly marked as tainted due to issues it caused, not some licensing philosophy.

https://lkml.org/lkml/2011/10/6/317

Incorrect. The kernel devs specifically cited the quality of the drivers when adding it to the taint list. Check the mailing list if you don't believe me.

https://lkml.org/lkml/2011/10/6/317

    The number of bug reports we get from people with virtualbox loaded are
    truly astonishing.  It's GPL, but sadly that doesn't mean it's good.
    Nearly all of these bugs look like random corruption. (corrupt linked lists,
    corrupt page tables, and just plain 'weird' crashes).

And the no-GUI, geared-towards-commandline, doesn't-have-directories-with-spaces type stuff is just my personal preference, as I've already said.

Virt-manager uses QEMU and I think it is pretty good, and much faster than Virtualbox. If you wish to use a desktop though, you should configure the video card of VM manually, its performance is not that good, but if you really want to use desktop VM, I suggest VMWare, I found the interaction much faster, but Virtualbox is pretty good to.

In short, QEMU with KVM is way faster, for servers, non-gui interactions.

It runs non-x86 binaries.

Oops, you are correct. Good catch!

That is also the compiler required for FreeDOS; an effort towards creating a free replacement would be helping multiple projects.

QEMU/KVM are the default virtualization used in OpenStack [1], for one. I also use it on my laptop to host guests because of how much Virtual Box sucks under Linux [2], as others have mentioned.

[1] https://www.openstack.org/

[2] https://lkml.org/lkml/2011/10/6/317

VGA Passtrough

The best reason, IMO, is that the tools around KVM (using QEMU) and virt-manager are becoming much more pleasant to use than their VirtualBox counterparts. The GUI could still use some cleaning up, IMO, but overall I have found the experience much more pleasant in recent virt-manager releases than the VirtualBox way of doing things.

Well, to be fair it's a QEMU newsgroup and its full listing is gmane.comp.emulators.qemu.

It's an emulator for a wide variety of hardware platforms. You'd care if you wanted an emulator for a platform it supported.

QEMU (short for "Quick EMUlator") is a free and open-source hosted hypervisor that performs hardware virtualization. QEMU is a hosted virtual machine monitor: It emulates central processing units through dynamic binary translation and provides a set of device models, enabling it to run a variety of unmodified guest operating systems. It also provides an accelerated mode for supporting a mixture of binary translation (for kernel code) and native execution (for user code), in the same fashion as VMware Workstation and VirtualBox do. QEMU can also be used purely for CPU emulation for user-level processes, allowing applications compiled for one architecture to be run on another.

http://en.wikipedia.org/wiki/QEMU

http://en.wikipedia.org/wiki/QEMU

Thanks for that perspective, that's a good way of looking at it. It's easy to get overly dismissive and lazy and it's good to have a reality check.

Yeah, looking at it again, you're right, I was lazy and obnoxious. My comment should have been "For those who don't know what QEMU is (I didn't), it is ...". Won't do it again.

http://bit.ly/HYBvy1

https://duckduckgo.com/?q=qemu

I get and share this complaint for random new startups that nobody has ever heard of before, and where the link is to the page that should be telling me what it is.

But this is an old, well-known project. If you put "QEMU" into Google, literally every single hit in the first page of results is about it.

This is simply awesome. Congratulations!

http://en.wikipedia.org/wiki/DESQview

Ovfconverter should be able to go both ways and translate the configuration to and from what you want. Naturally there are some limitations, as not all hypervisors support what other hypervisors support, visa versa.

https://www.vmware.com/support/developer/ovf/

Ok, but what about everything else in a .vmx (memory configuration, network configuration, serial device configuration)?

You can try using virt-tools (e.g. libvirt, virt-v2v). I think virt-v2v may do what you want: https://access.redhat.com/site/documentation/en-US/Red_Hat_E...

Thanks, this looks very helpful.

Helpful, thanks. But I'm reminded of my brother's email about how simple it was to create a Linux kernel for a tv-controller - 3 pages of build instructions, ending with "So easy!" What is it about Linux folks ...

Thanks. That makes sense. I think I should have phrased that question (#3) differently, since there's a huge difference between relative and absolute speed & performance.

What I had read as implied in the SO answer I linked to was that there was some other means of implementing cross-architecture emulation that was faster than QEMU.

In other words, there's a difference between being "slow" in absolute terms vs. being "slow" relative to other virtualization solutions.

From your answer, I gather that QEMU isn't under-performant relative to other emulation options.

Yes, I think Richard Henderson put in some effort in optimising TCG, which has helped.

My take on the KVM vs TCG split is simply that in the end open source projects are driven by the people who put in the work, and inevitably if there's a set of people whose day job is to work on the project then it's going to tend to improve in the areas those people and companies need. And in general the people working on the emulation side of things seem to be happy enough with the performance levels we currently have: I see plenty of patches to add new ARM boards or fix issues with devices, or to fix bugs in the linux-user emulation code. In comparison, there doesn't really seem to be much interest in TCG performance (and serious improvements in performance, though possible, would be a six month or longer project to achieve).

The particular bugs you note are even further out in the cold since x86 guest TCG in particular is pretty much orphaned and MIPS is not a great deal better (though I have been heartened to see recent contributions from Imagination).

"Tiny Code Generator", the JIT for cross architecture emulation.

QEMU on its own is not a virtualization system, just an emulator.

Thanks. That's an important distinction I had gotten wrong.

The QEMU wikipedia page describes it as "a free and open-source hosted hypervisor that performs hardware virtualization." [1]. In the context of the entire article, that description is slightly misleading.

[1] http://en.wikipedia.org/wiki/Qemu

Bingo. In fact I remember using QEMU briefly some years before virtualization or "VMWare" was even a widely-known term, and that was only because of my interest in the emulation scene at the time.

KVM supports nested virtualization, so you can run Xen inside a KVM VM. VMware does as well.

Xen paravirt has always run inside VMs, even before nesting support. I used to run it in VMware all the time for development purposes.

You seem to be laboring under some serious misapprehensions here. QEMU is very much a virtualization solution. It calls itself an emulator because it's older than the name 'virtualization.'

QEMU is an emulator, it isn't by itself capable of doing virtualization. It can allow a hypervisor to do CPU (and some I/O) virtualization in lieu of QEMU doing binary translation/emulation. In that case QEMUs purpose is mainly I/O emulation. 'Virtualization' as a name and concept predates QEMU by several decades.

KVM is merely the kernel infrastructure that enables ring-0 access for faster hardware access. For many years it was called qemu-kmod; to this day the actual process that you run is called 'kvm-qemu.'

kqemu and KVM are technologically unrelated.

You are overstating the difference between 'virtualization' and 'emulation.' There really isn't one. What used to be called 'emulation' is nowadays called 'full-virtualization' as opposed to 'paravirtualization.' QEMU, KVM, and XenKVM are full-virt, while traditional Xen is paravirt.

Para-Virtualization is the concept where the guest OS is aware that it is being run on a hypervisor. For example using hypervisor hypercalls to create new address spaces rather than setting up hardware page tables. "Full" or hardware level virtualization happens when the guest OS does not need to be aware of this fact. Neither is related to emulation.

KVM is not a hypervisor;

It is.

libvirt is.

This one isn't.

Xen blurs the line between virtualization platform and hypervisor because both pieces ship within the same project. Either libvirt or Xen can act as hypervisor for QEMU or KVM.

"hypervisor":"virtualization platform" ~ "kernel":"operating system". KVM and Xen can act as hypervisor for Qemu managed by libvirt.

If you are talking about running Windows specifically under KVM, then switch your display from VNC to Spice, change the video adapter to QXL and inside the Windows VM install spice-tools from http://www.spice-space.org/download/binaries/spice-guest-too...

This alleviates some of the problems you are referring to.

It was certainly not created for server virtualization, though that may be the primary use with present-day Qemu.

I mostly use Qemu for cross-architecture emulation, where the convenience to simulate certain embedded architectures and devices makes it very interesting to use. The integrated GDB server is also very neat, especially for kernel debugging.

Flashing and testing embedded devices is cumbersome, so using an emulator is preferable to speed up the code-build-test-debug loop. Runtime speed is not always that important.