QEMU under Slackware
Page created: 2023-07-20 , updated: 2023-08-02Sometimes you have to run a full guest operating system. In my case, I have to run some Windows garbage under "actual" Windows (Wine won’t cut it).
This is often refered to as KVM/QEMU:
-
KVM - Kernel-based Virtual Machine (wikipedia.org)
-
QEMU - Quick Emulator (wikipedia.org)
If I understand it correctly, the relationship between these two is that KVM provides the main virtualization support for the guest OS at the CPU level and it only works if the underlying processor supports virtualization. QEMU does everything else, including emulation of non-CPU hardware as needed. QEMU takes care of the details of running KVM for you.
KVM shows up as a device, so if you can see this, you should be good to go:
$ ls /dev/kvm /dev/kvm
But it might not be a bad idea to check for the kernel modules. I see a main KVM module and also an architecture-specific module:
$ lsmod | grep ^kvm kvm_amd 143360 0 kvm 1064960 1 kvm_amd
I’m running an AMD CPU, so that checks out. (The columns are: "Module", "Size", and "Used by").
Install QEMU
There’s a Slackbuild for that:
The README with the Slackbuild looks a little scary at first (so many options!), but
it’s actually all good news. Most things are turned on by default and it even sets
up QEMU to be accessible to the users group, so you don’t have to mess about with
permissions.
The QEMU docs look really great:
While the project doesn’t want to discourage users from using the command line to launch VMs, we do want to highlight that there are a number of projects dedicated to providing a more user friendly experience. Those built around the libvirt framework can make use of feature probing to build modern VM images tailored to run on the hardware you have.
It continues with "That said, the general form of a QEMU command line can be expressed as:…".
Informative, personable, and helpful. Excellent stuff.
Anyway, I’m convinced. I think I’ll use one of those interfaces.
But first, let’s see if it works:
$ qemu-system-x86_64
Opens a new window running the VM:
Looks good so far! It might be fun to test with an OS install ISO. A good option here is Alpine Linux. A lot of people use it for VM installs because it’s so lightweight. That also makes it great for low-power machines like my old EeePC 701 netbook, or just for people who prefer a more BSD-like Linux experience without a lot of cruft and bloat. It’s my favorite distro right after Slackware.
There’s a nice little package especially tailored for VM installs that comes to just 55Mb. That’s a much better choice than a full Slackware install for a quick test:
Let’s see if I can use Alpine real quick using nothing but the defaults:
$ qemu-system-x86_64 -cdrom Downloads/alpine-virt-3.18.2-x86_64.iso
Yeah, no problem. Well, one problem: udhcpc (provided by Busybox) was
unable to connect to a broadcast address, so networking wasn’t setup.
I’m guessing that’s because networking isn’t one of the QEMU defaults.
(Also, to release the keyboard and mouse from QEMU, you use
CTRL+ALT+g. This is for QEMU’s GTK frontend, which is the
default.)
Anyway, looks good. Now let’s see about one of those graphical front-ends.
Trying virt-manager, a GUI for QEMU
This one looks good:
It has a fairly good-sized tree of dependencies. So I’ll use the Slackbuild Queue Generator to resolve those for me:
# sqg -p virt-manager
Here’s the list (in install order):
spice-protocol spice spice-gtk gtk-vnc yajl libvirt libvirt-python libvirt-glib osinfo-db-tools osinfo-db libosinfo virt-manager
I got bored reading about each of these packages (hey, I have my limits too!) so I’m just going for it and installing the lot. We’ll see what happens when I run it…
Uh oh:
The Details box shows:
Unable to connect to libvirt qemu:///system.
Failed to connect socket to '/var/run/libvirt/virtqemud-sock': No such file or directory
Libvirt URI is: qemu:///system
Traceback (most recent call last):
File "/usr/share/virt-manager/virtManager/connection.py", line 923, in _do_open
self._backend.open(cb, data)
File "/usr/share/virt-manager/virtinst/connection.py", line 171, in open
conn = libvirt.openAuth(self._open_uri,
File "/usr/lib64/python3.9/site-packages/libvirt.py", line 147, in openAuth
raise libvirtError('virConnectOpenAuth() failed')
libvirt.libvirtError: Failed to connect socket to '/var/run/libvirt/virtqemud-sock': No such file or directory
Well, guess I need to do a bit more reading, then.
Okay, I forgot about this part in the virt-manager README:
>To run virt-manager as a normal user, you need to configure libvirt to have the correct permissions. Uncomment the unix_sock_group and unix_sock_rw_perms in /etc/libvirt/libvirtd.conf and add the user to the group libvirt uses.
Hmmm…
85:unix_sock_group = "users" 108:unix_sock_rw_perms = "0770"
Those look fine to me. I’m certainly a member of "users"…
Ah, here’s what I missed:
It’s plain as day in the Slackbuild’s README (this is what I get for my impatience):
If you want to start the libvirt daemon at boot, add this
to /etc/rc.d/rc.local
# Start libvirt:
if [ -x /etc/rc.d/rc.libvirt ]; then
/etc/rc.d/rc.libvirt start
fi
and if you want it to stop at shutdown add this to
/etc/rc.d/rc.local_shutdown
# Stop libvirt:
if [ -x /etc/rc.d/rc.libvirt ]; then
/etc/rc.d/rc.libvirt stop
fi
So I added those so it’ll be available on boot next time. And then
started libvirt manually for the current boot.
root@pluto:~# /etc/rc.d/rc.libvirt start Starting virtlockd: /usr/sbin/virtlockd -d Starting virtlogd: /usr/sbin/virtlogd -d Starting libvirtd: /usr/sbin/libvirtd -d
Restarted virt-manager and it looks like it connected to QEMU/KVM!
Great!
Moving on, virt-manager seems to come with no documentation and its website
has only an FAQ and screenshots: https://virt-manager.org/.
Here’s this Fedora Magazine article from 2019, though:
So now we start with a "Create a new virtual machine" button.
And now I’ve got simple options:
The next screen lets me select the ISO (I’ll pick that little Alpine installer again.) The "Choose the operating system you are installing" option is a little annoying. If it doesn’t autodetect, you have to uncheck the "Automatically…" box and then type something in the search field.
I’m installing Alpine 3.18, but the closest available version in the search box is 3.17. Let’s see what happens…
(I chose all defaults after that: storage, networking, etc.)
Then it starts up immediately!
This time eth0 is available as a network interface in the installer.
And udhcpc was able to do broadcast discovery!
Yeah, this is working. Doing a disk installation now… Man, I love the Alpine installer.
Reboot…yup, looking good.
Let’s do something fun:
# vi /etc/apk/repositories # uncomment the 'community' repo # apk update # apk search nethack # apk add nethack # nethack
I am quickly killed by a monster. Excellent.
Windows 10
Archive.org has a copy of the Windows 10 Enterprise 2016 LTSB ISO:
(As far as I’m concerned, Windows 7 was the last version worth running. Windows 2000 is probably still my favorite, though.)
Virt-manager correctly detected the ISO as Windows 10 and the installer started right up:
Windows worked fine. I used IE to download Firefox and networking was no problem. Really impressed by how easy this was to install and how well it works! I definitely recommend virt-manager.
But the LTSB version of Windows 10 doesn’t come with the Microsoft Store and it appears to be extremely difficult to install. My final goal with this is to play Minecraft Bedrock with my kids and Microsoft has made it…painful, almost to the point of cruelty.
Anyway, let’s continue the adventure here: minecraft_vm.
(LOL, after all the above worked, I couldn’t start X11 ("X Windows") the next morning. I checked the X11 logs and it said something about a virtual keyboard, so I figured it had to be related. But after fruitlessly pursuing that for a while, I realized my disk was full. This drive is way smaller than I’d remembered and adding a second 40Gb Windows installation had completely filled it.)