QEMU gives a guest a computer to boot: virtual CPU, memory, disks, firmware, network devices, and a display or console. On Linux, it can hand CPU execution to KVM, which uses the processor’s virtualization features. QEMU can also emulate a machine in software. The libvirt QEMU/KVM guide documents the available accelerators.
Libvirt sits above QEMU as a management layer. A VM definition records its devices and settings in a form tools can inspect and start again. That beats reconstructing an old command line from shell history when a disk or network interface needs changing. Libvirt’s passthrough security notes explain why devices and permissions should be declared clearly.
The boundary deserves attention. A shared host directory, bridged network, USB passthrough, or GPU passthrough gives the guest a path to something on the host. Add those capabilities only when the experiment needs them. A snapshot can save the guest’s current state before a risky change; important files still need a backup outside the VM’s storage.
For a first test machine, keep it plain: a known ISO, virtual disk, modest memory, and no host folders. Add networking when there is a reason. When something breaks, a short device list makes it easier to find the cause.
That is the appeal of virtualization for tinkering: another operating system is a few explicit settings away, and the main machine does not have to become the test bench.