35

I investigated this topic and here are my conclusions (But I still have questions. And please correct me if I made any mistake in my conclusions):

VMWare:

VMWare developed its VM Hypervisor SW in 1999, but it was proprietary.

QEMU:

4 years later after VMWare, French developer Fabrice Bellard developed QEMU (Quick Emulator) Hypervisor in 2003 and made it free and open source. QEMU then became a "full virtualization" type 2 hypervisor after years of community development.

  • QEMU is able to emulate various of HWs including CPU and I/O devices.
  • QEMU is able to interpret instructions sent to VM's vCPU to real instructions and send them to the physical CPU.
  • Some QEMU emulated devices are widely used by the virtualization softwares such as VirtualBox.
  • QEMU has its own GUI and CLI.

QEMU is able to run independently without any other VM SW.

HW virtualization:

Both Intel and AMD rolled out their HW virtualization technology (VT-x and AMD-V) in 2006.

KVM:

In 2006, A small company (which was acquired by Red Hat 2 years later in 2008) developed a loadable kernel module for Linux called "KVM" which is able to create VMs using the HW virtualization technologies just mentioned before. It was then officially merged into Linux kernel in 2007.

  • KVM doesn't emulate vCPU but rather uses HW virtualization technologies provided by Physical CPU.
  • As a Linux kernel component, KVM has neither GUI nor CLI. One has to write, say C code to call KVM kernel module to create VM, making it not directly usable to end users.
  • KVM is deemed as a Hypervisor.

KVM is able to create VMs independently without the support of any other Hypervisors such as QEMU.

libvirt:

As there are many Hypervisors in the market, libvirt was developed in the end of 2005 to unify the API and CLI of creating and managing VM's. From the point of view of end users, it provides CLI tools such as:

  • virsh
  • virt-manager
  • virt-install

libvirt itself doesn't create or manage virtual machines but rather maps the command issued by the user to one or a series of API calls to the underlying Hypervisor.

libvirt is free and open source.

virt-manager:

When people use KVM to create VMs, they probably see this screen:

Virtual Machine Manager GUI

I used to consider this SW as KVM's GUI, but after my investigation I found that it is another SW called "Virtual Machine Manager", as what the title shows. It is called virt-manager, too. virt-manager is backed by Red Hat.

According to its website, virt-manager primarily targets KVM VMs, but also manages Xen and LXC. See Virtual Machine Manager official web site.

virt-manager is built on top of libvirt. i.e. it focuses on user interfaces (both GUI and CLI). For the underlying VM management, it simply calls libvirt, which finally calls the underlying Hypervisor, such as KVM.

My Questions:

  1. Is there any mistake in my conclusion?
  2. Why virt-manager GUI shows "localhost (QEMU)" or "QEMU/KVM" in its VM list when I create KVM virtual machine?
  3. libvirt claims that almost any virtualization tool that starts with virt-* are libvirt tools, especially virt-manager and virt-install. See lib-virt FAQ. But virt-manager alcal virt-install is part of virt-manager. See virt-manager web site. So which one is correct? What exactly does virt-install and virt-manager belong to?
  4. Some articles talk about qemu-kvm, but as per my investigation, they are just two different Hypervisors. I'm able to use KVM independently to create VMs, then why should I use qemu-kvm? And what is qemu-kvm? It's QEMU which uses some KVM features when necessary or it's KVM which has to use some QEMU features otherwise it won't be able to create VMs?
storsan
  • 93
  • 9
Columbia Rover
  • 453

1 Answers1

32

KVM is able to create VMs independently without any support of ther Hypervisors such as QEMU.

Yes and no; it can create VMs but cannot provide hardware other than CPU & RAM.

Why virt-manager GUI shows "localhost (QEMU)" or "QEMU/KVM" in its VM list when I create KVM virtual machine?

KVM does not work on its own; it's only an API provided by the kernel for userspace. Just as you noted: "As a Linux kernel, KVM have neither GUI nor CLI. One have to write, say C code to call KVM module to create VM, making it useless to the end users."

So, end users typically use KVM through QEMU (where it is present as an acceleration method). You start the VM using the already familiar qemu CLI and just add -accel kvm or -enable-kvm (older versions). There are quite a few other KVM-using VM managers such as kvmtool, but QEMU is the most popular.

The same applies to libvirt – it doesn't manage KVM directly but just starts QEMU with the right options.

Additionally, KVM does not emulate most hardware – it won't provide the VM with a disk or with a network card; it only provides the hooks necessary to allow a userspace program to do so. KVM itself primarily deals with just the privileged CPU instructions.

This means that there's another advantage in using QEMU – you can use all the emulated hardware (SCSI adapters, Ethernet controllers) which QEMU already has implemented, instead of having to do it from scratch.

libvirt claims that almost any virtualization tool that starts with virt-* are libvirt tools, especially virt-manager and virt-install. See lib-virt FAQ.

Such claims are unenforceable. If someone else wants to use virt-* for their program's name (especially when the program primarily manages libvirt anyway), then they can just name it virt-*.

Some articles talk about qemu-kvm, but as per my investigation, they are just two different Hypervisors. I'm able to use KVM independently to create VMs, then why should I use qemu-kvm? And what is qemu-kvm? It's a QEMU which uses some KVM features when neccessary or a KVM which have to use some QEMU features otherwise it won't be able to create VMs?

Originally it was a fork of QEMU, with KVM-based acceleration support added. Later it was merged back into mainline QEMU, so the qemu-kvm command became just qemu -enable-kvm (and later was adjusted to qemu -accel=kvm).

grawity
  • 501,077