zlacker

[return to "We replaced Firecracker with QEMU"]
1. gwd+j3[view] [source] 2023-07-10 14:29:35
>>hugodu+(OP)
Listen people, Firecracker is NOT A HYPERVISOR. A hypervisor runs right on the hardware. KVM is a hypervisor. Firecracker is a process that controls KVM. If you want to call firecracker (and QEMU, when used in conjunction with KVM) a VMM ("virtual machine monitor") I won't complain. But please please please, we need a word for what KVM and Xen are, and "hypervisor" is the best fit. Stop using that word for a user-level process like Firecracker.
◧◩
2. Muffin+Qc[view] [source] 2023-07-10 15:10:45
>>gwd+j3
> virtual machine monitor

Is it good to think of libvirt as a virtual machine mointor, or is that more "virtual machine management"?

◧◩◪
3. zbroze+Yf[view] [source] 2023-07-10 15:24:01
>>Muffin+Qc
I'd love to get a clear explanation of what libvirt actually does. As far as I can tell it's a qemu argument assembler and launcher. For my own use-case, I just launch qemu from systemd unit files:

https://wiki.archlinux.org/title/QEMU#With_systemd_service

◧◩◪◨
4. Muffin+Ol[view] [source] 2023-07-10 15:49:40
>>zbroze+Yf
> As far as I can tell it's a qemu argument assembler

Raises a few questions to me:

Can you use KVM/do KVM stuff without QEMU?

Can you do libvirt stuff without QEMU?

Hoping the answers to both aren't useless/"technically, but why would you want to?"

◧◩◪◨⬒
5. jonono+Bp[view] [source] 2023-07-10 16:08:14
>>Muffin+Ol
libvirt supports other hypervisors than QEMU, such as VirtualBox, Xen and LXC.
◧◩◪◨⬒⬓
6. Muffin+Uq[view] [source] 2023-07-10 16:13:46
>>jonono+Bp
I know ChatGPT responses get downvoted here but I fed it this to help me better understand this:

> is KVM a hypervisor? is it type 1 or type 2? is QEMU a hypervisor, is it type 1 or type 2? if QEMU is using KVM, is QEMU then not a hypervisor in that use case?

Yes, KVM (Kernel-Based Virtual Machine) is indeed a hypervisor. It's a type 1 hypervisor, also known as a "bare metal" hypervisor. This is because KVM directly runs on the host's hardware to control the hardware and to manage guest operating systems. The fact that it's a Linux kernel module that allows the Linux kernel to function as a hypervisor makes it very efficient.

QEMU (Quick Emulator) is a bit more complex. By itself, it is technically a type 2 or "hosted" hypervisor, meaning it runs within a conventional operating system environment. QEMU is a generic, open-source machine emulator and virtualizer that can emulate a variety of hardware types and host a range of guest operating systems.

However, when QEMU is used with KVM, the picture changes somewhat. In this case, KVM provides the hardware virtualization where it allows the host machine to call CPU instructions of full virtualization. Then, QEMU emulates the hardware resources and provides the user interface for the VM, thus allowing for better performance and usability. It's this combination of KVM's hardware acceleration capabilities and QEMU's emulation capabilities that makes them often used together.

In this case, QEMU is not acting purely as a hypervisor; it's providing hardware emulation and user interface for the VMs, while KVM is the part providing the hypervisor functionality. However, we often refer to the combination of "QEMU/KVM" as a unit when talking about this mode of operation.

[go to top]