What's changed: Initial version (topic 2.05, subtopics 2.05.1–2.05.2)
5.2Creating and Managing Virtual Machines
Learn to create virtual machines with virt-manager (GUI) and virt-install (CLI), the difference between full virtualization and paravirtualization (virtio), lifecycle operations from the command line with virsh, and performance monitoring via virt-manager.
Once you understand how KVM works, the next step is operational: creating, running, and observing virtual machines. LinuC-2 expects you to create VMs from either GUI or CLI, choose how devices are presented (full virtualization or paravirtualization), and run day-to-day lifecycle operations with virsh.
5.2.1Creating virtual machines
- virt-manager is a GUI management tool for creating, starting, opening a console to, and reconfiguring VMs. Its wizard walks through ISO selection, CPU/memory allocation, and disk creation.
- virt-install performs the same creation process from the command line in one shot, suited to scripting and automated provisioning (e.g.,
virt-install --name vm1 --memory 2048 --vcpus 2 --disk size=20 --cdrom /path/to.iso).
5.2.2Full virtualization vs paravirtualization (virtio)
- Full virtualization emulates devices that look identical to real hardware for the guest. No guest OS changes are needed, but emulation overhead is higher.
- Paravirtualization reduces emulation overhead by having the guest use virtual device drivers optimized for the hypervisor. In KVM/QEMU environments, virtio is the standard implementation (virtio-blk for disks, virtio-net for networking, etc.).
- virsh operates a VM's lifecycle from the command line (
virsh list --allto list,virsh start/virsh shutdown/virsh destroyto start/gracefully stop/force-stop,virsh undefineto remove the definition). virt-manager can also monitor performance (CPU/memory usage, etc.).
Three points recur: virt-install can complete creation entirely from the CLI (good for automation), virtio is the standard paravirtualization implementation that cuts overhead, virsh destroy is a forced stop while virsh shutdown is graceful. The trade-off—full virtualization needs no guest changes but is slower, paravirtualization needs virtio drivers in the guest but is faster—is also a staple contrast.
In practice, the workflow splits by purpose: use the virt-manager wizard for a single ad hoc VM, but fold virt-install into a shell script when deploying dozens of identical VMs, for idempotent, reproducible provisioning. At creation time you choose between full virtualization and paravirtualization: the former requires no guest changes and pretends "real hardware is here," at the cost of emulation overhead. The latter—especially virtio, the KVM/QEMU standard—assumes virtio-aware drivers in the guest and simplifies the communication path with the hypervisor, substantially improving disk I/O and network throughput. Because most Linux distributions ship virtio drivers out of the box, the general rule of thumb is default to virtio unless there is a specific reason not to. Day to day, without opening the GUI, you list state with virsh list --all, start with virsh start vm1, ask the guest OS for a graceful shutdown with virsh shutdown vm1, and—as a last resort when it does not respond—force-stop with virsh destroy vm1 (the equivalent of pulling the power plug). For ongoing performance observation, the standard practice is checking CPU, memory, disk I/O, and network graphs in virt-manager's detail view.
| Item | Full virtualization | Paravirtualization (virtio) |
|---|---|---|
| Guest-side changes | Not required | Requires virtio-aware drivers |
| Performance | Higher emulation overhead | Faster via a simplified I/O path |
| Example devices | Emulated real-hardware-equivalent devices | virtio-blk, virtio-net |
Trap: "virsh destroy deletes the VM's definition on disk" is wrong—virsh destroy only force-stops it (equivalent to a power cut); removing the definition is virsh undefine. Also wrong: "paravirtualization needs no guest OS changes"—paravirtualization (virtio) requires compatible drivers in the guest; it is full virtualization that needs none.
5.2.3Section summary
- virt-manager = GUI creation / virt-install = one-shot CLI creation (automation-friendly)
- Full virtualization = no guest changes but slower / paravirtualization (virtio) = needs guest drivers but faster; operate with virsh start/shutdown/destroy/undefine
Sign in to track progress — Log in.
Quick check
(just a quick review)Q1. You need to automatically provision 50 identically configured virtual machines via a script. Which creation method fits best?
Q2. You prioritize disk I/O throughput and want to use devices optimized for KVM/QEMU with matching drivers installed in the guest. Which approach should you adopt?
Q3. A virtual machine vm1 has stopped responding. You need to stop it immediately, equivalent to cutting the power. Which command is appropriate?
Keep track of your progress
The full study guide is free to read. Sign up free to practice with the question bank, track what you have read, review your mistakes, and highlight passages.