Hacker Neue

Preferences
wtallis parent
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.

stanakama
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.

pm215
There are a bunch of errors here:

* 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

mpyne
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.
kijiki
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.

bstx
> 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.

doktrin
> 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

This item has no comments currently.