<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Kvm on Le Site de François</title><link>https://lesitedefrancois.be/en/tags/kvm/</link><description>Recent content in Kvm on Le Site de François</description><generator>Hugo -- gohugo.io</generator><language>en</language><copyright>© 2026 François</copyright><atom:link href="https://lesitedefrancois.be/en/tags/kvm/index.xml" rel="self" type="application/rss+xml"/><item><title>KubeVirt</title><link>https://lesitedefrancois.be/en/security/kubevirt/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://lesitedefrancois.be/en/security/kubevirt/</guid><description>&lt;p&gt;&lt;strong&gt;KubeVirt&lt;/strong&gt; is a CNCF project that makes Kubernetes a native hypervisor management plane, allowing KVM virtual machines to be declared, scheduled, and operated through the Kubernetes API without a separate virtualisation management layer. The motivating use case is organisational convergence: teams running a mix of legacy VM workloads and modern containerised services no longer need two separate platforms (an OpenStack or vSphere cluster for VMs, a Kubernetes cluster for containers) with separate networking, storage, RBAC, and CI/CD integration. With KubeVirt, both workload types live in the same cluster, share the same &lt;code&gt;kubectl&lt;/code&gt; and GitOps tooling, and are subject to the same scheduling, resource quota, and network policy primitives. KubeVirt reached 1.0 in 2023 and is the engine behind &lt;strong&gt;Red Hat OpenShift Virtualization&lt;/strong&gt;, the downstream product used by organisations migrating away from VMware.&lt;/p&gt;</description></item><item><title>KVM/QEMU</title><link>https://lesitedefrancois.be/en/security/kvm-qemu/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://lesitedefrancois.be/en/security/kvm-qemu/</guid><description>&lt;p&gt;&lt;strong&gt;KVM&lt;/strong&gt; (Kernel-based Virtual Machine) and &lt;strong&gt;QEMU&lt;/strong&gt; (Quick Emulator) solve different halves of the same problem and are almost always used together. &lt;strong&gt;KVM&lt;/strong&gt; is a Linux kernel module that turns the kernel into a hypervisor: with &lt;strong&gt;Intel VT-x&lt;/strong&gt; or &lt;strong&gt;AMD-V&lt;/strong&gt;, guest CPUs run on real hardware at near-native speed and guest memory is managed through extended page tables. KVM has no device model of its own — no disk, network, or firmware emulation. &lt;strong&gt;QEMU&lt;/strong&gt; supplies that in userspace (virtio, USB, VGA, ACPI) and controls KVM by issuing &lt;strong&gt;ioctl&lt;/strong&gt; calls on &lt;strong&gt;&lt;code&gt;/dev/kvm&lt;/code&gt;&lt;/strong&gt; — creating VMs, mapping memory, running vCPUs via &lt;code&gt;KVM_RUN&lt;/code&gt; — while &lt;strong&gt;QMP&lt;/strong&gt; exposes external management over a Unix socket. &lt;strong&gt;libvirt&lt;/strong&gt;, originally from Red Hat, sits above both: it translates &lt;strong&gt;domain XML&lt;/strong&gt; into QEMU command lines and lifecycle operations. The stack is the default on Linux: &lt;strong&gt;RHEL&lt;/strong&gt; ships &lt;code&gt;qemu-kvm&lt;/code&gt;, &lt;strong&gt;OpenShift Virtualization&lt;/strong&gt; runs &lt;strong&gt;KubeVirt&lt;/strong&gt; (&lt;code&gt;virt-launcher&lt;/code&gt; → libvirt → QEMU), and &lt;strong&gt;OpenShift Sandboxed Containers&lt;/strong&gt; uses &lt;strong&gt;Kata Containers&lt;/strong&gt; with the same hypervisor to isolate pods in micro-VMs.&lt;/p&gt;</description></item><item><title>libvirt</title><link>https://lesitedefrancois.be/en/security/libvirt/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://lesitedefrancois.be/en/security/libvirt/</guid><description>&lt;p&gt;&lt;strong&gt;libvirt&lt;/strong&gt; is an open-source library, daemon, and toolset that provides a unified, stable API for managing virtualisation infrastructure — virtual machines, storage volumes, virtual networks, and host devices — across multiple hypervisor backends. It was originally written by Daniel Berrange at Red Hat and has since become the standard virtualisation management layer on Linux, underpinning &lt;strong&gt;KubeVirt&lt;/strong&gt;, OpenStack Nova, oVirt/RHEV, Proxmox, and the &lt;code&gt;virsh&lt;/code&gt; / &lt;code&gt;virt-manager&lt;/code&gt; administrative tools. The core value proposition is &lt;strong&gt;hypervisor abstraction&lt;/strong&gt;: the same &lt;code&gt;libvirt&lt;/code&gt; API call creates a VM on KVM/QEMU, Xen, LXC, or (historically) VMware ESXi, without the management layer caring about the underlying implementation. In practice, the KVM/QEMU driver is the dominant use case on Linux; the others are progressively less-maintained but remain supported. libvirt communicates with hypervisors through driver-specific mechanisms — with QEMU, it generates the full QEMU command line from the domain XML definition and manages the QEMU process lifecycle, communicating with the running VM through the QEMU Monitor Protocol (QMP) over a Unix socket.&lt;/p&gt;</description></item></channel></rss>