QEMU looks interesting. I have a few questions about its intended use case.
1. My understanding is that the primary use case of QEMU is for server virtualization on Linux hosts leveraging KVM. Is there a use-case for QEMU on non-Linux hosts?
2. I have read that QEMU excels in server virtualization but lags behind VirtualBox in desktop virtualization. Is this still the case? [1]
3. Is it considered "slow" for cross-architecture virtualization? [1]
Whether you think it's "slow" for cross-architecture use depends on your standards. It's always going to be slower than using the native CPU, because we have to emulate everything, and even with a JIT that's not going to be fast. Empirically not much effort is being put into trying to make the emulation/JIT faster (and there are serious technical obstacles as well as mere lack of effort/time), but if your target being emulated is a 200MHz embedded dev board then we can probably manage to go as fast as that in software... In any case the QEMU target is often more convenient for debugging or simply more easily available than the real hardware.
It is sometimes a bit disheartening to see so much development effort go toward the virtualization/KVM/Xen side rather than seeing improvements in TCG. I realize that Redhat (and maybe others?) funds a lot of development in that area, so it's natural that that's where most of the improvements are. I mostly use QEMU as a CPU emulator, though, and it's frustrating to see so little activity on the TCG side, especially when it comes to things like bugfixes (Win7 x64 bluescreens under TCG, mipsel loadvm broken, to name two issues that have bitten me).
Still, kudos to the developers for making some things better (TCG actually does seem noticeably faster in 2.0.0) and congratulations on the 2.0.0 release!
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).
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.
QEMU is used by pretty much all open-source emulation or virtualization systems. Bits of it are even used by VirtualBox. QEMU on its own is not a virtualization system, just an emulator. KVM is the hypervisor most closely associated with QEMU, but it also works out of the box with Xen. Using QEMU with either of those hypervisors works just as well as VirtualBox for desktop and workstation virtualization needs, with the only significant downside being that QEMU isn't tightly coupled to a single standard GUI for management. Using QEMU for cross-architecture emulation (not virtualization) is slow, because that's an inherently high-overhead task. I don't think QEMU sets any records for being particularly fast or slow at cross-architecture emulation.
Running two x86 hardware-assisted hypervisors at once is madness. However, running one inside another is possible.
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.' 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.'
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.
KVM is not a hypervisor; libvirt is. 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.
QEMU's lack of hard-dependency on a specific gui is in fact its strength, not its weakness. This makes it much easier to modularize and deploy at scale, which is what OpenStack does, for instance. Every QEMU VM is capable of listening on a given port for VNC connections, which means you don't even particularly need a GUI for basic use. More featureful guis can be found in the libvirt project (e.g. virt-manager).
QEMU is not particularly fast at cross-architecture stuff because that was not its original focus. However, it was one of the first packages available for linux that even made that possible at all, which is why it is still known for this functionality.
* QEMU calls itself an emulator because emulation was its original intent; that it was possible to relatively easily modify it to use hardware virtualization rather than emulating the CPU was a happy accident some time later
* for the CPU the "virtualization"/"emulation" distinction is huge -- if you can use the CPU's hardware assist to directly run guest code things will be fast; if you're emulating the guest CPU things will be very much slower
* the process being run isn't "kvm-qemu" unless your distro
is providing back-compatibility wrappers (which in turn are only there because the changes to QEMU to make it work with KVM were for some years maintained out of tree)
* KVM is absolutely a hypervisor; libvirt is not, it is a management layer that can configure and control a hypervisor
* you can't use Xen with KVM, because they're both hypervisors
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.
> 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.
> 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.
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.
I have read that QEMU excels in server virtualization but lags behind VirtualBox in desktop virtualization. Is this still the case?
I am not an expert in this area, but I find it to be the case for me. Running a desktop guest under kvm is a pain - I'm about to move to a new workstation and am considering moving to virtualbox. My desktop guest under kvm doesn't accept the mouse scroll wheel, doesn't support clipboard copying, doesn't support dynamic desktop resizing, and virtualbox does. These things are theoretically fixable with kvm, but there's no clear and easy path to fix them (or wasn't, last I checked. I tried a few things and failed). Virtualbox just has 'install guest additions' and you're done.
I've not tried virtualbox for servers - the perception I had was that the management tools were really focused around desktops.
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.
1. My understanding is that the primary use case of QEMU is for server virtualization on Linux hosts leveraging KVM. Is there a use-case for QEMU on non-Linux hosts?
2. I have read that QEMU excels in server virtualization but lags behind VirtualBox in desktop virtualization. Is this still the case? [1]
3. Is it considered "slow" for cross-architecture virtualization? [1]
[1] http://superuser.com/questions/447293/does-qemus-performance...