Não foi possível terminar a instalação: ‘internal error: qemu unexpectedly closed the monitor: 2017-10-04T12:13:03.898997Z qemu-system-x86_64: -chardev pty,id=charserial0: char device redirected to /dev/pts/0 (label charserial0)
Could not access KVM kernel module: Permission denied
2017-10-04T12:13:03.899071Z qemu-system-x86_64: failed to initialize KVM: Permission denied’
Traceback (most recent call last):
File “/usr/share/virt-manager/virtManager/asyncjob.py”, line 89, in cb_wrapper
callback(asyncjob, *args, **kwargs)
File “/usr/share/virt-manager/virtManager/create.py”, line 2545, in _do_async_install
guest.start_install(meter=meter)
File “/usr/share/virt-manager/virtinst/guest.py”, line 498, in start_install
doboot, transient)
File “/usr/share/virt-manager/virtinst/guest.py”, line 434, in _create_guest
domain = self.conn.createXML(install_xml or final_xml, 0)
File “/usr/lib/python2.7/site-packages/libvirt.py”, line 3640, in createXML
if ret is None:raise libvirtError(‘virDomainCreateXML() failed’, conn=self)
libvirtError: internal error: qemu unexpectedly closed the monitor: 2017-10-04T12:13:03.898997Z qemu-system-x86_64: -chardev pty,id=charserial0: char device redirected to /dev/pts/0 (label charserial0)
Could not access KVM kernel module: Permission denied
2017-10-04T12:13:03.899071Z qemu-system-x86_64: failed to initialize KVM: Permission denied
That’s one approach. Another would be to use systemctl to find the main process and use ps to find the user:
~ systemctl status libvirtd
● libvirtd.service - Virtualization daemon
Loaded: loaded (/usr/lib64/systemd/system/libvirtd.service; enabled; vendor preset: enabled)
Active: active (running) since Wed 2017-10-04 07:51:26 PDT; 4h 16min ago
Docs: man:libvirtd(8)
http://libvirt.org
Main PID: 798 (libvirtd)
CGroup: /system.slice/libvirtd.service
├─798 /usr/sbin/libvirtd
├─868 /usr/bin/dnsmasq --conf-file=/var/lib/libvirt/dnsmasq/net1.c...
└─869 /usr/bin/dnsmasq --conf-file=/var/lib/libvirt/dnsmasq/net1.c...
~ ps u 798
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
root 798 0.0 0.0 363636 16924 ? Ssl 07:51 0:00 /usr/sbin/libvi
Since you’re running as root, I’m not sure why this isn’t working.
Have you updated your kernel since rebooting? If that’s the case, you’ll need to reboot to get everything working. (I know Antergos and Arch update quite often)
Well, I wasn’t quite sure if I had updated the kernel today but I did a reboot anyway.
Didn’t work.
Just to add some more information about this, I am trying to create a VM using an .iso that is on a secondary drive.
I merely installed qemu and virt-manager, and enabled/started the libvirtd service.
I have another box with similar hardware where I run fedora 26, and there I simply did:
On this computer I don’t have any VM because of the error on the OP.
Nothing complex at all. I just like to have a few VM’s on hand for testing purposes at work.
I tried adding my user to the libvirt group, and now virt-manager no longer ask for the root password, but the same error appears when I try to finalize a VM.
Interesting. I’m glad you were able to solve this, but I’m going to do some digging into this. I’m spinning up a beefy instance right now to test the problems with the “QEMU/KVM” option.
So, QEMU/KVM session connects to a libvirtd daemon running as your user. (it will launch on if there isn’t already one running) This is a bit interesting because usually you don’t have problems accessing kernel modules as root, but as an unprivileged user, you can. I suppose this is another idiosyncrasy of Ubuntu.
EDIT: WAIT! vms run as the qemu user when you’re running a qemu:///system environment, I wonder if we need to change some udev rules or something to get this to work properly.
One way or another, you’ve got it working and it’s really not a problem which one you use because there shouldn’t be a limitation.
What do you mean by limited? What exactly is being limited under this connection type?
Well I didn’t solve it per se, I just found out something interesting.
Another interesting thing I found out is that I only encounter this problem in arch based distros. In Fedora I just need to install the packages and that’s it!
By limited I mean that, because qemu:///session runs libvirtd as a user and not root, this means that any VM configuration that requires root privileges won’t be available, this is notorious in the networking department.
I think that hardware passthrough (at least through pci) isn’t available as well.
Me neither, and since I’m all ready a member of these groups:
I think the solution goes a bit beyond group associations.
Besides that, I took a look at the configuration files for libvirt and polkit as they were mentioned in the Wiki, and they seem to be correctly configured in terms of permissions.
