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