I was trying to spin up a KVM again after previous success with openBSD KVM, but instead of virt-install
, this time using XML file as I think it will pave way for future automation. And man it was a struggle for a 2 full nights. I was at the verge of “cheating” with virt-manager
because of its GUI and being more beginner-friendly. But I decided to take the hard way to understand each line of the XML file and the proper way to spin up KVMs. Here are what I learned:
-
KVM is NOT really a type-1 hypervisor in the sense I thought it was. It’s not similar to ESXi. It’s more of a technology, a module of Linux kernel that allows virtualization instead of a standalone hypervisor.
-
By installing Alma linux under a minimal virtualization host profile (headless), I has hoped it would remove the overhead as much as possible for it to be as similar to a bare-metal hypervisor like ESXi. This is so far not wrong.
-
Then comes
qemu
. Turns out it is QEMU that do a lot of high-level virtualization such as setting up environment, emulating different architecture, OS, virtual devices etc., while KVM takes care of closer-to-kernel stuffs like hardware virtualization extension on CPUs, CPU and memory management etc. I had no idea what it was until going through the book that showed how to use qemu to spin up VMs. -
Finally on top of everything,
libvirt
is the management tool to manage KVMs, providing a management layer that makes it a bit more similar to ESXi. -
It could be said that
kvm
+qemu
+libvirt
+ a GUI VM manager (such as virt-manager, Cockpit etc.) function the same way as ESXi. -
Set SELinux enforcing mode to “Permissive” to have an easier time learning. Leaving it on only adds another layer of complexity to the task at hand.
-
If you want to “talk” to the VMs, you have to setup console. And the device “graphics” here doesn’t have anything to do with displaying GUI, but to simply display text on terminal. I was so confused to see what “graphic” has to do with “console” (Hey! I’m not trying to use desktop environment here!!)
<graphics type='vnc' port='5900' listen='<your_host_ip_address>'/>
-
I got stuck with several half-installed VMs because I didn’t have any way to connect to it. Can’t create new domains with the same name, but
virsh list --all
didn’t show anything, sovirsh destroy
didn’t work. I can see the process intop
, but killing the process won’t help either. It felt like I was stuck in a limbo and only a reboot might help. Turned out, justvirsh undefine
the name of the VM. -
Also, running
virsh
under user and under rootsudo virsh
shows totally different list of VMs. Looks like each user will only see the VM they started. I only know about this when I look at the list of VM in Cockpit. Little obscured things like this is hard to know because you don’t even know what you don’t know. -
Learning from books or resources that’s 3 or 4-year old can really be outdated already, and especially when many failed to mention how to setup the environment properly to reproduce what is being taught. This can be a HUGEEE source of frustration if learners are not aware from the start.
-
I couldn’t locate where
qemu-kvm
emulator is to pass into the XML file. Triedwhich qemu-kvm
orrpm -ql qemu-kvm
ordnf provides qemu-kvm
but still couldn’t find the binary. Butdnf provides \*/qemu-kvm
shows exactly where. -
Libvirt has excellent documentation for the XML file, though I need to know some other thing more because I can understand it fully.
-
Sometimes the easy path can enlighten the difficult path. In this case, when I still can’t seem to define the VNC console in the XML file, I peeked into the XML editor of
virt-manager
and instantly understand where I got wrong, and gain another level of understanding how to config a VM.
Self-teaching is messy. One might need to jump from this resource to the next, from the official documentation to some large language models, or to a youtube video of some random Indian dude. If it helps me move forward and keep the learning pace, it’s good.