Comment by stanakama | Hacker News Reader

Comment by stanakama | Hacker News Reader

Parent Full thread

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.

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

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.

Reply on news.ycombinator.com