Getting started with qemu September 10, 2018 on Drew DeVault's blog

I often get asked questions about using my software, particularly sway, on hypervisors like VirtualBox and VMWare, as well as for general advice on which hypervisor to choose. My answer is always the same: qemu. There’s no excuse to use anything other than qemu, in my books. But I can admit that it might be a bit obtuse to understand at first. qemu’s greatest strength is also its greatest weakness: it has so many options that it’s hard to know which ones you need just to get started.

qemu is the swiss army knife of virtualisation, much like ffmpeg is the swiss army knife of multimedia (which comes as no surprise, given that both are written by Fabrice Bellard). I run a dozen permanent VMs with qemu, as well as all of the ephemeral VMs used on builds.sr.ht. Why is it better than all of the other options? Well, in short: qemu is fast, portable, better supported by guests, and has more features than Hollywood. There’s nothing other hypervisors can do that qemu can’t, and there’s plenty qemu can that they cannot.

Studying the full breadth of qemu’s featureset is something you can do over time. For now, let’s break down a simple Linux guest installation. We’ll start by downloading some install media (how about Alpine Linux, I like Alpine Linux) and preparing a virtual hard drive.

curl -O https://nl.alpinelinux.org/alpine/v3.8/releases/x86_64/alpine-standard-3.8.0-x86_64.iso
qemu-img create -f qcow2 alpine.qcow2 16G

This makes a 16G virtual hard disk in a file named alpine.qcow2, the qcow2 format being a format which appears to be 16G to the guest (VM), but only actually writes to the host any sectors which were written to by the guest in practice. You can also expose this as a block device on your local system (or a remote system!) with qemu-nbd if you need to. Now let’s boot up a VM using our install media and virtual hard disk:

qemu-system-x86_64 \
    -enable-kvm \
    -m 2048 \
    -nic user,model=virtio \
    -drive file=alpine.qcow2,media=disk,if=virtio \
    -cdrom alpine-standard-3.8.0-x86_64.iso \
    -sdl

This is a lot to take in. Let’s break it down:

-enable-kvm: This enables use of the KVM (kernel virtual machine) subsystem to use hardware accelerated virtualisation on Linux hosts.

-m 2048: This specifies 2048M (2G) of RAM to provide to the guest.

-nic user,model=virtio: Adds a virtual network interface controller, using a virtual LAN emulated by qemu. This is the most straightforward way to get internet in a guest, but there are other options (for example, you will probably want to use -nic tap if you want the guest to do networking directly on the host NIC). model=virtio specifies a special virtio NIC model, which is used by the virtio kernel module in the guest to provide faster networking.

-drive file=alpine.qcow2,media=disk,if=virtio: This attaches our virtual disk to the guest. It’ll show up as /dev/vda. We specify if=virtio for the same reason we did for -nic: it’s the fastest interface, but requires special guest support from the Linux virtio kernel module.

-cdrom alpine-standard-3.8.0-x86_64.iso connects a virtual CD drive to the guest and loads our install media into it.

-sdl finally specifies the graphical configuration. We’re using the SDL backend, which is the simplest usable graphical backend. It attaches a display to the guest and shows it in an SDL window on the host.

When you run this command, the SDL window will appear and Alpine will boot! You can complete the Alpine installation normally, using setup-alpine to install it to the attached disk. When you shut down Alpine, run qemu again without -cdrom to start the VM.

That covers enough to get you off of VirtualBox or whatever other bad hypervisor you’re using. What else is possible with qemu? Here’s a short list of common stuff you can look into:

There’s really no excuse to be using any other hypervisor1. They’re all dogshit compared to qemu.


  1. Especially VirtualBox. If you use VirtualBox after reading this article you make poor life choices and are an embarrassment to us all. ↩︎

Have a comment on one of my posts? Start a discussion in my public inbox by sending an email to ~sircmpwn/public-inbox@lists.sr.ht [mailing list etiquette]

Articles from blogs I read Generated by openring

SourceHut API 2.0 dev log

Completing the project now known as “API 2.0” is one of the most important steps in finalizing the sr.ht beta, and I’ve been trying to keep the community abreast of developments, especially on the sr.ht-dev mailing list. I’m summarizing for the blog as well t…

via Blogs on Sourcehut September 25, 2020

People expect technology to suck because it actually sucks

I get at least 27 tech annoyances on a single day

via tonsky.me September 25, 2020

Rewriting the Technical Interview

Frigitt, vi danser For et øyeblikk, vi leker Vi tusen små bladskiper Gleder oss, på det klare morgenlys The mothercone unfurls her softening scales, and in the time of days I am emancipated. Adrift in the chill dawn light, my siblings flutter, slender forms c…

via Aphyr: Posts September 18, 2020