QEMU/KVM/virt-manager installed but I can't make virtualization work.
 

I decided to see if I could move from VirtualBox to QEMU/KVM for virtualizing. I managed to get things installed by using the SBOpkg list from this thread: https://www.linuxquestions.org/quest....php?p=6394372

I had to juggle some configuration files and user settings, and I got limited success.

I can run virt-manager and get the interface. I managed to get the KVM modules installed and the libvirtd and QEMU services running.

First thing, I start virt-manager and it informs me that KVM is not available. I query the modules and get back that there are three KVM modules running.

I try to create a VM without KVM, and when I go to connect to an ISO file, I get "Failed to connect socket to '/var/run/libvirt/virtstoraged-sock': No such file or directory.

At this point, I'm wondering how much effort to put into this, given that I have a working solution in VirtualBox.

This is on Slackware64-15.0

I have QEMU 8.1.1 and Virt-Manager 4.1.0 installed WITHOUT KVM and run virtual machines running ReactOS, Devuan, Arch Linux, Alpine, KolibriOS, Lilidog, TinyCore, and Sparky Linux. (NOT all at once.) It all works.

I am running on a DELL laptop running Manjaro Linux stable, and I keep it up to date. Kernel version 6.6.0. My desktop i KDE Plasma on Wayland.

What do you have?

Versions of things.
 

virt-manager 4.1.0 and QEMU 7.2.1.

My system is a Frankensteined concoction of an ASUS motherboard with 64GB of RAM and an Intel i7 processor and assorted add-ons.

I tend toward SlackBuilds and and QEMU 7.2.1 is what is there. If 8.1.1 is likely to work I can try compiling that. I have nothing to lose as it isn't working now.

Do you think I should try that, or would I be spinning my wheels?

I understand that the KVM isn't critical for function, which I is why I tried without it. While better performance would be nice, nothing I do in VMs required blazing speed, just functioning software.

#1 I would not think it a good idea to apply any urgency to this, since you already have a working solution.

#2 I have not read the release notes for the change QEMU 7 to 8 for a long while, but I do not recall anything there that should be a stopper.

#3 I would be embarrassed to tell you how much LONGER (decades) it has been since I touched slackware!

QEMU is the more "Linuxy" and FOSS way to do this, so one would thing that SOMEONE more current on Slack' would chime in with advice. Keep trying.

You might have to "tune" VirtManager a bit, but QEMU under VirtM gets tuned BY VirtM and that seems to work better for me than manual control. Could it be something in your build of VirtM that is the problem? Because that is where I would look next.

Looking at the SlackBuild for virt-manager, there is a dependency tree.
You need to start at the bottom and work up.
e.g. build and install the spice-protocol package, then build and install the spice package, then build and install the spice-gtk package.
Repeat for the other dependencies, then build virt-manager.

Like many Slackware users, for me this just creates increased complexity with ongoing maintenance problems.

Far easier just to run QEMU from a simple script.
Something like this will get you going
To access help on options, try 'qemu-kvm -help | less'.

To access an install iso file, add a line like
under the -drive line in the above script.

For me, QEMU is cleaner, faster and easier to maintain on Linux than VirtualBox.

For KVM, you need:
1. Support in your CPU. AMD and Intel call it by different names.
2. Support/enabled in BIOS.
3. Support in-kernel (usually via kmods).

I use QEMU all the time and it works well for a variety of VMs. I use the 8.0.x branch because 8.1.x has broken cursor support in the SPARC emulator with Solaris. Never used virt manager. I learned with just the QEMU command lines so that's what I used. Compicated at first, but once you get used to it they are not too bad. Usually you can copy/paste what you used last time and just tweek it for your next machine. The Slackware packages are old so I built from source. You night need some extra Python stuff to build the docs.

I will take the above information and see what I can do.

Thanks.

Quick update - test worked, need to fine-tune, but progress.
 

I used the command line listed above, tweaked for my test, with a recent version ReactOS.

I needed to run the command with sudo prefixed, and it worked. It did not mess with the permissions of my .qcow2 file, which is stored under my normal user ID. I might need to add some group permissions that I haven't done, either correctly or yet.

The performance was absolutely blazing. I was able to install ReactOS in about a minute and a half. I'll be looking into things like enabling networking and such, but that is hopefully just a matter of reading documentation.

Thanks.

No... This is a problem with SBO packages. Actually KVM and QEMU works out of the box on Slackware. You can test that by enabling KVM and installing QEMU only, it will work. One of the problems here is that you don't understand what you are doing. If you did, you'd know how to find out what the issue is, the order of finding out and so fourth.

Let's just simply say that this is the order of things.. 1. kvm 2. qemu 3. libvirt, 4. virt-manager. This is also the order you have to check where the issue is.. With SBO package this is not transparent. However, I can tell you the problem is most likely with libvirt somehow. QEMU is complex, but out of those packages, libvirt adds the most complexity.

When you say the problem is virtualization is not working on your machine, that's very generic. It probably works! There can be a thousand different problems with your settings though. You need to narrow down the problem a great deal. One of the first things you can do is to try to run QEMU/KVM directly, without libvirt and virt-manager.

Have a look at this page:
https://docs.slackware.com/howtos:em...manage_install

It might give you some pointers, and tips of things you can try. I'm not saying you need to install everything yourself, but see how it works, and how complex it is, and what the order of things is. That way you can try to figure out the problem in the right order, and narrow things down.

KVM is not supported and will not run on my hardware. QEMU and VIRT-MANAGER work just fine without it.

Yeah, ofcourse. KVM works provided the CPU supports it.

The fact that I am asking questions here is because I don't understand what I am doing. The idea is to ask for help and see what I can learn. You may not have intended it that way, but that sort of comment is the sort of thing that gives Linux forums a bad reputation among new Linux users.
I will have to look and see if I can rip out the software stack and rebuild it without any form of Slackbuild. Prior to this thread I had not heard of sbopkg, and that was a learning experience. I'll have to figure out if I can back out the installs I did with it to try a full rebuild of the various VM packages. Alternatively, based on what you said about it, I might try to just clear out libvirt and try a plain-source install.
If you had fully read the thread, you would have seen that my opening post gave some additional information like getting a KVM unavailable message from virt-manager, and also in a later post that using some command-line suggestions from allend enabled me to set up a virtual machine, KVM working and all. The problem is something is off with virt-manager so I can't use it to control my VMs. My initial plan was to see if I could get things like networking going and worry about virt-manager later, but as it appears that libvirt also has to do with networking, I may go the route of seeing if sorting out libvirt will help, then hammering out whatever comes up next.
I will look into that and see if I can learn anything useful. Thanks for the link.

Well, I didn't mean to come off like that. I was just checking, plus, it was a way for me to ask you to start from the beginning.
SBO package isn't necessarily the problem in itself, but the problem with something like that is you don't really know how it sets things up, and if you're fresh to what you're doing it will makes it more difficult to find the problem.

I mentioned 1-4 in my previous post, those are the 4 elements of the virtualization package, keep that in mind.

What virt-manager says is pretty much irrelevant, it's the last thing you should "solve", because it's #4 on the elements. To figure out the problem(s), you need to deal with the 3 other ones first. And for us here on the forum, if we should be able to help you, the issue needs to be narrowed down quite alot.

KVM is really a very basic thing, and like others here say, you can run QEMU without KVM. But, ofcourse, you want KVM working. So, how can you check if it works?

Try this (in a terminal as root):

1. Check if you have a CPU that support virtualization
2. Check if kvm is loaded
and/or
This should give you an indication that your machine supports virtualization AND that KVM is enabled in the kernel and loaded. If it is, great, you can use full virtualization, if not, then you need to load kvm. However, this is not the most important step. You can even skip this step.

You can quickly test QEMU in many different ways. One way is to boot a kernel image with it directly. Copy any kernel image (ex.vmlinuz-huge-5.15.19) from /boot to /home/user, then run the following command (or something similar):
The Kernel will panick, since it doesn't have an init or filesystem or anything like that, but don't worry about that. Just close QEMU.

This will simply verify if QEMU is working as expected. If KVM is enabled, it should be fairly fast. So, you can even run this without kvm enabled, and perhaps it is much slower, if it is, then kvm is most likely working when you boot with it enabled like above. You can do many different kind of test runs with QEMU, even booting CD's and all kind of things like that. Running virtual machines this way is very flexible, and only the limits of QEMU (which aren't that many) and your imagination will limit what you can do this way.

But, you probably want to make this easy. So.. With the abovesteps you will know if QEMU-KVM is working as it should. If it does, the problem is with libvirt and/or virt-manager. Give it a go to narrow down the problem.

The KVM modules are there, and I have already stated that I was able to install an operating system using QEMU with KVM enabled from the command line, though I did have to use sudo to make it work. I was able to boot from an iso file to do the installation. I can boot the VM, though without networking I can't do much. Still, progress is progress.
By the time I am asking for help here, easy has run off screaming into the hills. I'll settle for getting things working. I'm a command-line geek from way back. If I can figure out networking support, I have no problem whipping up scripts to start up VMs. I'm still trying to get a coherent picture of how QEMU handles networking.

If I have understood what I've read correctly, I need libvirt for networking. virt-manager would be a "nice to have", but I can live without it. I use bridged networking on VirtualBox so that I can connect between the host and guests. I want to be able to do the same under QEMU. I have libvirtd running, for what that's worth.

Actually, that's quite useful. It tells me you want to run the VM as a user (qemu///session). Actually, the problem could very well be with authorization. Yes, you can't start the VM with KVM as user in QEMU, because the user don't have access to read/write /dev/kvm. Libvirt is like I said very complex, and among other things responsible for making things like network function easily with minimal manual setup, and libvirt does many things like that.

At the end of the link I gave you, there is another link:
http://docs.slackware.com/howtos:emu...config_methods

Have a look at it please. It goes through some of those things. If you are very lucky, it's just a matter of giving virt-manager the right permissions with polkit and/or setting up KVM for user.


Yes, pretty much.
First things first. Ideally if you don't mind it, you should run libvirt daemons as root, that gives libvirt the access it needs to set all those things up quite easily. You need to check how your libvirt daemons run, and what access they have. In the article above, the method is described. If libvirt daemons run as root and work as they should, they grant access to /dev/kvm to setup a user session (or qemu system). You don't have to run the libvirt daemons as root, but it makes things more complicated to run them as user.
Secondly virt-manager must have the right access in polkit, as mentioned above, otherwise it can't use libvirt to run qemu/kvm, even if every other authorization is correct, regardless of how you want to run things. But like you said, you don't HAVE to use virt-manager, but it sure makes things more neat. Some people use virsh instead, others use another thing like virt-manager, but less complex (don't remember the name of it). I think everything you need is in that article above, with that you should be able to figure it out.

Actually, virtualization is complicated, so don't give up. With all these 4 components, it's very convenient and easy actually, once you get it set up properly. Right now it seems there are some twisted threads, and those just need untangling.