[SOLVED] QEMU/KVM/virt-manager installed but I can't make virtualization work.
Linux - SoftwareThis forum is for Software issues.
Having a problem installing a new program? Want to know which application is best for the job? Post your question in this forum.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
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.
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.
I found a few things that I put in some of the config files. My major irritation on KVM giving a not present message was a permissions issue. As a rule I try not to muck about in the /dev directory, and I found that the default permissions on /dev/kvm were root,users. Adding my user ID to the users group (my brain kind of fizzed on the whole one-group-per-user change) cleared the KVM error.
Quote:
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.
I have been running libvirtd from root, it had never occurred to me that a daemon process could be run from a regular user ID.
Quote:
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.
Courtesy of those links you provided, I have made some progress with configurations. Chasing a few networking threads I found that I needed to enable slirp with the configure command to get networking. I am currently recompiling QEMU with that change. I had started setting up another ReactOS virtual machine and found virt-manager choking on all forms of networking, so I chased link threads. If I understand it right, this will also create a new utility for configuring bridged networks. In case you are not familiar with it, ReactOS is an open source attempt at a Windows clone. Lacking the bloat of real Windows, it makes for a quick install test.
We'll see what happens when the compile is done (Currently at about 50% complete). Crossing fingers, toes, eyes...
SLIRP This is the default networking backend and generally is the easiest to use.
Quote:
In most cases, if you don't have any specific networking requirements other than to be able to access to a web page from your guest, user networking (slirp) is a good choice. However, if you are looking to run any kind of network service or have your guest participate in a network in any meaningful way, tap is usually the best choice.
Personally, I use a tap interface.
On Slackware, this requires:
- having a bridge set up on the host machine
- building QEMU with the option BRIDGE_HELPER_SETUID=yes
- having a file /etc/qemu/bridge.conf containing 'allow <bridgename>'
- including this line in my QEMU start script
I found a few things that I put in some of the config files. My major irritation on KVM giving a not present message was a permissions issue. As a rule I try not to muck about in the /dev directory, and I found that the default permissions on /dev/kvm were root,users. Adding my user ID to the users group (my brain kind of fizzed on the whole one-group-per-user change) cleared the KVM error.
With libvirt as root (daemon), having /dev/kvm with root as group (default) should not be an issue, that's the preferable way. Libvirt should take care of it. And yea, it's a good idea not to muck about in /dev directory, if possible.
So, did you get it up and running then?
I mean, before you recompiled QEMU..
Once it's properly up and and running, there's just too many different things you can do with VM's, it's quite interesting. And kvm/qemu/libvirt are all great. While virt-manager is nice and all, I do find that it is missing a few things.
You can make that even smaller, as long as bridge helper is setuid and br0 is allowed in /etc/qemu/bridge.conf. It will just use the defaults, which is "qemu-bridge-helper" and "br0".
Code:
-netdev bridge,id=net0
I used that for FreeDOS last night and it made tap9, plugged it into br0, and set it up. When I shutdown FreeDOS it was removed. With the "device" it became:
With libvirt as root (daemon), having /dev/kvm with root as group (default) should not be an issue, that's the preferable way. Libvirt should take care of it. And yea, it's a good idea not to muck about in /dev directory, if possible.
So, did you get it up and running then?
I mean, before you recompiled QEMU..
Once it's properly up and and running, there's just too many different things you can do with VM's, it's quite interesting. And kvm/qemu/libvirt are all great. While virt-manager is nice and all, I do find that it is missing a few things.
I had it running without KVM complaints, but it turns out that recompiling QEMU broke things. I now get "Error: No hypervisor options found for this connection" when using the user connection.
It looks like I need to figure out what I broke and then see what I can extract from the new batch of posts. I may try just recompiling with no options and see if that gets me back to no errors on the user session. Once there, I can try recent suggestions.
I'll come back in an hour or three with updated results.
After recompiling with no selected options, I am getting the same error. I've actually managed to break things worse. The error appears now on both user session and system session. Trying to invoke QEMU from the command line is also broken. When I try to start QEMU from the shell, I get unknown options for enable-kvm, smp and so forth.
Hmm.. it's easier to do this if you package QEMU in the default Slackware way (makepkg/txz). That way you can easily remove it as well. I suggest you give it a go, that way you can clean up remaining QEMU components that may be laying around. It's quite easy, and also described in that link.
QEMU has alot of compile options, and it takes a very long time to compile, unless you remove all the machines you know you don't need and/or just stick to x86_64.
Hmm.. it's easier to do this if you package QEMU in the default Slackware way (makepkg/txz). That way you can easily remove it as well. I suggest you give it a go, that way you can clean up remaining QEMU components that may be laying around. It's quite easy, and also described in that link.
QEMU has alot of compile options, and it takes a very long time to compile, unless you remove all the machines you know you don't need and/or just stick to x86_64.
I'll look at the packaging instructions and see what I can figure out.
As for the other machines, part of why I'm looking into QEMU is the number of options for architecture.
I tried following the instructions. First finding is that as written, the instructions are impossible to follow. I have to write to locations where only root can. I simply spent the whole session as root to get around that problem.
After plowing through lots of compiling, I got stuck in stage 2.
While attempting to configure vde-2-master, this happened:
Code:
# autoreconf –install
autoreconf: 'configure.ac' or 'configure.in' is required
# autoreconf configure.ac –install
configure.ac:14: error: required file './compile' not found
configure.ac:14: 'automake --add-missing' can install 'compile'
configure.ac:17: error: required file './config.guess' not found
configure.ac:17: 'automake --add-missing' can install 'config.guess'
configure.ac:17: error: required file './config.sub' not found
configure.ac:17: 'automake --add-missing' can install 'config.sub'
configure.ac:7: error: required file './install-sh' not found
configure.ac:7: 'automake --add-missing' can install 'install-sh'
configure.ac:17: error: required file './ltmain.sh' not found
configure.ac:7: error: required file './missing' not found
configure.ac:7: 'automake --add-missing' can install 'missing'
src/Makefile.am: error: required file './depcomp' not found
src/Makefile.am: 'automake --add-missing' can install 'depcomp'
autoreconf: automake failed with exit status: 1
# ls -l
total 956
-rw-r--r-- 1 root root 18003 Apr 22 2023 COPYING
-rw-r--r-- 1 root root 26436 Apr 22 2023 COPYING.libvdeplug
-rw-r--r-- 1 root root 9790 Apr 22 2023 Changelog
-rw-r--r-- 1 root root 576 Apr 22 2023 INSTALL
-rw-r--r-- 1 root root 2127 Apr 22 2023 Makefile.am
-rw-r--r-- 1 root root 7921 Apr 22 2023 README
-rw-r--r-- 1 root root 372257 Nov 12 21:39 aclocal.m4
drwxr-xr-x 2 root root 4096 Nov 12 21:39 autom4te.cache/
-rwxr-xr-x 1 root root 489336 Nov 12 21:39 configure*
-rw-r--r-- 1 root root 10065 Apr 22 2023 configure.ac
drwxr-xr-x 4 root root 4096 Apr 22 2023 doc/
drwxr-xr-x 2 root root 4096 Nov 12 21:39 include/
drwxr-xr-x 2 root root 4096 Apr 22 2023 m4/
drwxr-xr-x 2 root root 4096 Apr 22 2023 man/
drwxr-xr-x 10 root root 4096 Apr 22 2023 src/
# ./configure --libdir=/usr/local/lib64
configure: error: cannot find install-sh, install.sh, or shtool in "." "./.." "./../.."
no, you don't have to do it all.. Only for QEMU.. Do QEMU as normal, but install it to /some/location (DESTDIR=), then use makepkg to make a package of that location. Something like this:
Code:
./configure --libdir=/usr/local/lib64
make -j4
make DESTDIR=/some/location/ install
cd /some/location/
makepkg ../qemu-packagename.txz
If you're unsure it's better not to do it. But you can do it all as user too, but you have to make sure permissions are set correctly after, otherwise you'll brick your whole filesystem. /some/location can be any location, one readable/writable as root or as user. But when you package the thing with makepkg, the folders have to be set with root as owner/group (set safe permissions YES), either before or during that stage.
Once all that is done and you have a QEMU package, you can install it with installpkg qemu-packagename, and then you can also remove it with removepkg qemu-packagename. The advantage of this is to easily remove all the files.. You can do this to remove any old/problematic files you installed when you installed QEMU manually previously.
Just to double check your package to make sure it has the right permissions, you can put it somewhere, run explodepkg and check the filetree of that package with ls -lshR /some/location.. To make sure there are no files owned or grouped as user..
It's a simple process. It's the same as the one you used to manually install QEMU, except you don't install it, you package it with 2 different steps at the end basically. The link was just to show the process, but there is another link in there at the vert start with a red textbox warning. That's the link you have to use to find out how to best package everything instead of installing it. That link is only about how you do that, and that's the process you have to learn, the simple one. It will help you clean up the mess you made when you manually installed QEMU, or at least that is the purpose of pointing you in this direction.
Ps. Don't do it if you don't understand the process. Rather go back and read the process again and understand it fully first.
I second that advice.
The OP got in trouble in the first place trying to do "easy" things that are NOT simple that the OP did not fully understand. That is a good thing to do form time to time, as you always LEARN things. Generally you do not make it better by adding more things that you do not understand to the mix.
With a package based Distro (ARCH, DEB, or RPM based for example) you get the benefit of people who KNOW what they are doing packaging the software so it will work on their distribution. If you are source based or modified source based then you need to know more about building software.
Sometimes the best answer is to back out and back off, then start over with steps you fully understand.
I second that advice.
The OP got in trouble in the first place trying to do "easy" things that are NOT simple that the OP did not fully understand. That is a good thing to do form time to time, as you always LEARN things. Generally you do not make it better by adding more things that you do not understand to the mix.
With a package based Distro (ARCH, DEB, or RPM based for example) you get the benefit of people who KNOW what they are doing packaging the software so it will work on their distribution. If you are source based or modified source based then you need to know more about building software.
Sometimes the best answer is to back out and back off, then start over with steps you fully understand.
The problem started when the SlackBuilds didn't work. I have found that in recent years, the builds are less likely to work for an increasing number of applications. I've resorted to AppImages and compiling from source, which for an increasing number of applications doesn't work either. Snap and Flatpak are not options because I can't compile the Snap or Flatpak managers using the SlackBuilds or direct sources..
I am trying to learn from this experience, but the results are mixed so far. I've got the compile running on QEMU now, we'll see if I've learned anything.
I completed the compile, packaged it up as indicated, cleared out the prior QEMU install to prevent interference, ans installed the package.
The results are interesting. Not useful, but interesting.
I still get an error that KVM is unavailable. I must have gunked something up.
I tried creating a VM with this setup, and it kind of sort of not exactly worked. I was able to use virt-manager to define a machine, set memory, CPU count and disk space, and point it to an ISO. I attempted to boot the VM, it booted from the ISO image, started loading the OS installer (ReactOS again) and when it went to switch video modes, the window went blank. It seems that the VM is running, but I can't see anything. Since Spice is being used for display, I'm wondering if I mangled that. The CPU load monitor indicates something is happening in there.
If you learn from your failures, it looks like I'll be learning a lot by the time I get this working.
The problem started when the SlackBuilds didn't work. I have found that in recent years, the builds are less likely to work for an increasing number of applications. I've resorted to AppImages and compiling from source, which for an increasing number of applications doesn't work either. Snap and Flatpak are not options because I can't compile the Snap or Flatpak managers using the SlackBuilds or direct sources..
I am trying to learn from this experience, but the results are mixed so far. I've got the compile running on QEMU now, we'll see if I've learned anything.
You could test Guix (not now, but at some point).. Not sure if it builds on Slackware with ease or not, but it's a useful concept and "package manager" for Slackware, for those in need of that.
Anyways, one of the issues with Slackbuilds is that you don't know how it was set up exactly, and there are things in there that could create issues. Especially if the target environment start to deviate.
I completed the compile, packaged it up as indicated, cleared out the prior QEMU install to prevent interference, ans installed the package.
The results are interesting. Not useful, but interesting.
I still get an error that KVM is unavailable. I must have gunked something up.
I tried creating a VM with this setup, and it kind of sort of not exactly worked. I was able to use virt-manager to define a machine, set memory, CPU count and disk space, and point it to an ISO. I attempted to boot the VM, it booted from the ISO image, started loading the OS installer (ReactOS again) and when it went to switch video modes, the window went blank. It seems that the VM is running, but I can't see anything. Since Spice is being used for display, I'm wondering if I mangled that. The CPU load monitor indicates something is happening in there.
If you learn from your failures, it looks like I'll be learning a lot by the time I get this working.
I dunno, but I think this is back to the point where we started, about setting the right authentication with libvirt etc.. Just take it all step by step.. I don't think the problem is related to QEMU, so that's probably the least thing you need to look at.
To ease your mind, you could try again to run qemu/kvm WITHOUT libvirt/manager, just to check.. It's fully possible to run VM's with only kvm/qemu actually, it's just kind of complicated to get up and run (super long commands). But you could do simplified test runs. Even back to the simplest example of just running a Kernel image in kvm/qemu.. It can tell you a a few things..
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
