[asciimov]

> Not sure what this means to be honest: [...]

As someone who also has similar frustrations as the author I can explain.

I don't regularly run virtual machines, but I have been doing it for decades now, for a long time the install process was: install VirtualBox (or equivalent), tell what resources to allocate including disc images, run the vm, install the os, and your good to go.

To install Qemu/kvm/lib-virt you first have to find an installer tutorial. Then you hit up your package manager (like apt or pacman) to put the software on your machine (notice I didn't say install), then you have to go about installing and linking together a mess of programs, gotta tell systemctl to start up some stuff, gotta configure some networking stuff, then hope it all starts up. And it doesn't, you need to get some other packages to fix something else that your tutorial never mentions. Get that installed, manually after finding a supposed fix on some random message board, then maybe lib-virt fires up without issue. You point it at the resources, get it started up to install the os, and find that your vm is dog slow. Now you find yourself installing more packages, configuring more files with hardware memory addresses, and adding kernel boot flags just to get graphics working better. You can easily spend hours on this if you hit the right hiccups along the way. All because you wanted to spend an hour or two on a different problem.

I too wish the install for qemu was just easier, it would be nice if the packages for it came with some sane defaults or an installer script to get you up and running with a minimum install.

[ssl-3]

I don't have very many machines running VMs, but IIRC the last time I set up libvirt (on a tiny, cheap Lenovo box to virtualize Home Assistant), it went something like this:

pacman -S virt-manager

...and the whole libvirt/KVM/QEMU dependency tree got pulled down, installed, fiddled whatever I needed to fiddle to make it start at boot, and it generally worked. I manage it with virt-manager on another machine.

Performance seems fine, and configuring the virtual machines themselves is not really much different with virt-manager than it is with virtualbox.

[jchw]

I still don't understand what this means. In Debian installing qemu is no different from installing any other package, including Virtualbox.

Like:

> edit random config files

I have no idea what config files you have to edit to run a relatively basic qemu incantation. My best assumption is that they mean libvirt, but I also don't really know what you have to edit to make libvirt work.

Since the OP is using Debian, I can check the Debian instructions for setting up a KVM libvirt setup on Debian.

https://wiki.debian.org/KVM#Installation

OK, this looks relatively straight-forward. You install packages, then you create VMs. It recommends AQEMU or virt-manager to use as a UI.

I am on NixOS because I like my coffee black, but I am kind of curious to see what the experience is roughly like, so maybe I can try to follow along in toolbox. It's not going to be identical but it shouldn't be any better of an experience than native Debian, for sure.

    $ toolbox create --image quay.io/toolbx-images/debian-toolbox:12
    ...
    $ toolbox enter debian-toolbox-12

Toolbox seems to mount some libvirt stuff in for convenience, but we want to actually run libvirtd in the toolbox container, so umount it. This doesn't need to be done on a real Debian installation.

    $ sudo umount /var/libvirt
    $ sudo umount /run/libvirt

Now following the Debian instructions:

    $ sudo apt update
    $ sudo apt install qemu-system libvirt-daemon-system
    ...
    $ sudo adduser john libvirt

Hmm, can't start libvirtd with no systemd, since I'm not on a real Debian machine. But, I can at least manually run libvirtd. Again, this doesn't need to be done on a real Debian installation.

    $ sudo libvirtd &
    $ sudo virtlogd &

OK. Theoretically the next thing I need to do is install the UI.

    $ sudo apt install virt-manager
    $ virt-manager

From here I had to Add Connection to connect to libvirt, but using the default settings worked. Admittedly this is not intuitive, but the UI will make you do it, so it's not like you can forget to.

Now I can create VMs! They don't really run in Toolbox for a variety of reasons that I could probably work around, but it's beside the point. On actual Debian this would be the end of things. Should be totally possible to install Windows 95.

--

Interestingly though, Debian recommends another tool called AQEMU before virt-manager. I think this is just a qemu frontend, so it probably doesn't need libvirt at all. (The instructions are unclear about this, which is very unfortunate.) I wonder how easy that is to use.

    $ sudo apt install aqemu
    $ aqemu

W00t, this one is really easy to use. No need to connect to libvirt, I created a Windows 9x VM pretty quickly. I am mildly alarmed that the default OS option is "Linux 2.6", the latest version of Linux that is in the list, and that the latest Windows version listed is "Windows 7". Since this just sets defaults it's not so important, but it definitely hints at this not being super maintained these days. Does it still work? Can I install and run Windows 98 in it?

Thankfully, yes. I followed the VM wizard using defaults, selecting only Windows 9x. Added CD-ROM image of Windows 98 SE, added a boot floppy (actually the Japanese DOS-V boot floppy for Windows 98, since that's all I had locally, still works with some awkwardness.) Started VM. Formatted, installed. (Mostly. It's actually sitting here on "Updating System Settings..." with "7 minutes remaining". But I reckon it'll be done in a couple more minutes.)

OK, so there you go: if you would like to use qemu+KVM to install Windows 9x, you absolutely can do it using aqemu on Debian 12. No need to edit random config files or even bother with libvirt, if you don't want to.

Well, given how long this post is, it certainly doesn't do anything to disprove the notion that Qemu is less accessible and intuitive to use for ordinary users than Virtualbox, that's for sure. And to be sure, I 100% agree and empathize with the fact that it is not, because it isn't.

That said, this only caught my attention because it seemed like the OP had gotten stuck in an unusually deep rut, as I have basically only ever needed to edit configuration files with qemu when doing ridiculous things in libvirt (like PCI-e passthrough and Looking Glass and the like.) Beyond that, setup and usage of qemu is typically not too bad, with the rather large caveat that you kind of have to know what to do.

[asciimov]

Thanks for the detailed write up.

I don't have full notes for my last adventure into QEMU, but you are correct that it was mostly an issue with libvirt and getting graphics to render correctly.

> Well, given how long this post is, it certainly doesn't do anything to disprove the notion that Qemu is less accessible and intuitive to use for ordinary users than Virtualbox, that's for sure. And to be sure, I 100% agree and empathize with the fact that it is not, because it isn't.

That's really the rub, choosing to be an ordinary user. The older I get the less I choose to tinker with things that I'm not going to use very often. I like it when software just sets itself up and lets me get to work.

[jchw]

This is true. If someone says "I just want something that works, and Virtualbox works" it doesn't really raise any eyebrows. It's really the tone of "I am unable to make QEMU/KVM work, since I am not a rocket scientist" that implies, maybe they would use QEMU, if only it wasn't horrifically difficult to get working. I think if your experience with QEMU is this bad, you may have just gotten a bit unlucky and gotten off into the weeds on a detour you probably did not need.

That said, are there reasons why someone who just wants things to work and doesn't want to tinker ever would choose QEMU over Virtualbox? Definitely. Here's a good one: the Virtualbox kernel modules were notoriously problematic. Back in the day, loading the vboxdrv module would add TAINT_CRAP in your running kernel[1], because the kernel developers were tired of dealing with bug reports that are the fault of the vboxdrv. Presumably it's better nowadays, but out-of-tree modules are generally a source of headache. Another good one is features: Virtualbox has a lot of great features for desktop end users, but QEMU can do a whole lot more; it supports absolutely tons of architectures and system options. You get access to a wide range of paravirtualization devices through Virtio drivers, including VirtioFS, a dramatically superior solution for mounting directories into VMs versus Virtualbox's Shared Folders feature, in my opinion. It's also possible to do a lot more advanced things, like setting up a discrete GPU passthrough and Looking Glass, or passing a portion of your Intel iGPU using GVT-g.[2]

Of course, some day Virtualbox may support a KVM backend, just as virtualization tools are starting to support unified hypervisor backends on Windows and macOS. There's even an existing patch, though I do not know what the status is and whether or not it could ever be merged upstream.[3] So maybe in the future, choosing between Virtualbox or KVM will become unnecessary.

For now though, it's definitely not clear what you should recommend to someone IMO. (For this particular use case, I don't even recommend a VM at all; I think for Windows 95, 86Box is a better solution.)

[1]: https://lkml.org/lkml/2011/10/6/317

[2]: https://wiki.archlinux.org/title/Intel_GVT-g

[3]: https://github.com/cyberus-technology/virtualbox-kvm, https://news.ycombinator.com/item?id=39300317

[gonzodaruler]

*

1 point by gonzodaruler 0 minutes ago | next | edit | delete [–]

> Of course, some day Virtualbox may support a KVM backend, just as virtualization tools are starting to support unified hypervisor backends on Windows and macOS. There's even an existing patch, though I do not know what the status is and whether or not it could ever be merged upstream.[3]

This is the official patch set for the VirtualBox KVM backend. Our plan is to support this for the near future. There are even packages for ArchLinux (AUR), gentoo and NixOS already if you want to test this.