FS#58894 - [libvirt] Set user and group failed after upgraded to 4.4.0-1
Attached to Project:
Community Packages
Opened by Patrick Young (kmahyyg) - Wednesday, 06 June 2018, 17:28 GMT
Last edited by Eli Schwartz (eschwartz) - Wednesday, 15 August 2018, 00:49 GMT
Opened by Patrick Young (kmahyyg) - Wednesday, 06 June 2018, 17:28 GMT
Last edited by Eli Schwartz (eschwartz) - Wednesday, 15 August 2018, 00:49 GMT
|
Details
Description:
After I upgraded to this version of libvirt, I cannot start the VM I created before via virt-manager. All configs are default files which are created in the installation. However, it works smoothly before I upgraded to this version. Additional info: Package Version: 4.4.0-1 Log: $ sudo virsh start win8.1 [sudo] password for kmahyyg: error: Failed to start domain win8.1 error: unable to set user and group to '65534:992' on '/var/lib/libvirt/images/win8.img': Success Permissions: # ls -alh /var/lib/libvirt drwxr-xr-x 12 root root 4.0K Jun 7 00:55 . drwxr-xr-x 36 root root 4.0K Jun 7 01:01 .. drwxr-xr-x 2 root root 4.0K Jun 6 22:41 boot drwxr-xr-x 2 nobody nobody 4.0K Jun 7 01:08 dnsmasq drwxr-xr-x 2 root root 4.0K Jun 6 22:41 filesystems drwxr-xr-x 2 nobody kvm 4.0K Mar 31 15:27 images drwxr-xr-x 3 root root 4.0K Jun 7 00:55 lockd drwxr-xr-x 2 root root 4.0K Jun 6 22:41 lxc drwxr-xr-x 2 root root 4.0K Jun 6 22:41 network drwxrwxrwx 8 nobody kvm 4.0K Jun 7 01:08 qemu drwxrwxrwx 2 nobody nobody 4.0K Jul 6 2017 sanlock drwxr-xr-x 2 root root 4.0K Jun 6 22:41 uml # ls -alh ./images/ total 31G drwxr-xr-x 2 nobody kvm 4.0K Mar 31 15:27 . drwxr-xr-x 12 root root 4.0K Jun 7 00:55 .. -rwxrwxrwx 1 nobody kvm 304M Mar 31 01:04 virtio-win-0.1.149.iso -rwxrwxrwx 1 nobody kvm 30G Jun 7 01:08 win8.img UID 65534 is user nobody. nobody:x:65534:65534:Nobody:/:/sbin/nologin UID 1000 is user kmahyyg. kmahyyg:x:1000:1000::/home/kmahyyg:/usr/bin/zsh GID 971 is group: libvirt:x:971:root,kmahyyg GID 992 is group: kvm:x:992:kmahyyg,root Steps to reproduce: $ sudo virsh start win8.1 Temporary Fix: > edit /etc/libvirt/qemu.conf, and uncomment the line that says "dynamic_ownership = 1" and change the 1 to a 0. Then restart libvirtd. Note that once you've done this, you'll need to make sure that all disk image files used by qemu are pre-set to the proper ownership for the "qemu user" to access them (this includes all parent directories of the image files) (the qemu user is "root" on many systems, but is "qemu" on some others (eg Fedora and RHEL). It may also be configured in /etc/libvirt/qemu.conf). according to https://www.redhat.com/archives/libvir-list/2011-April/msg01222.html What I may need to notice is that I didn't modify qemu.conf before I upgraded to this version, and it worked. |
This task depends upon
Closed by Eli Schwartz (eschwartz)
Wednesday, 15 August 2018, 00:49 GMT
Reason for closing: Fixed
Additional comments about closing: fixed upstream in 4.5
Wednesday, 15 August 2018, 00:49 GMT
Reason for closing: Fixed
Additional comments about closing: fixed upstream in 4.5
similarly for nobody it can be 99 or 65534 except inside systemd service files where systemd shorts the logic and always uses 65534
Goes back to
FS#54943and the entries added or not to the tmpfiles snippet.@loqs Sorry, I don't have much time for that now. I have an important exam to be prepared these days.
FS#58903is explained by https://bugs.archlinux.org/task/58375#comment169085 the broken implementation ofFS#566771) I began using ZFS long before support for ZFS was integrated into libvirt. Thus I usually create ZVOLs manually to be used as disks for VMs. In libvirt I have a storage resource for those ZVOLs which is the folder /dev/zvol/${ZFS filesystem name}. In this folder are symlinks that point to the block device files /dev/zd*. Those device files belong to root which cannot be changed and thus libvirt 4.4.0-1 fails.
2) Sometimes instead of creating a ZVOL I create a ZFS filesystem and create raw images for the VMs. This is mostly due to portability as copying image files is easier as copying ZVOLs. Again libvirt fails to change the owner.
Both cases happen on several PCs, some of which use UID 98 for nobody, others use UID 65534.
FS#58375including the original feature requester.But that really is
FS#58903unless you think these bugs share a common cause.will you cherry pick the fixes for
FS#58700so QEMU/KVM guests on AMD could use the kernel mitigations?Maybe you should drop glusterfs support.
# "ae102b5d7bccd29bc6015a3e0acefeaa90d097ac.patch::https://libvirt.org/git/?p=libvirt.git;a=patch;h=ae102b5d7bccd29bc6015a3e0acefeaa90d097ac")
# patch -p1 -i "${srcdir}"/ae102b5d7bccd29bc6015a3e0acefeaa90d097ac.patch
and the config option --without-xen which is no longer valid in the PKGBUILD
Edit enter triggered post instead of new line apologies
Error while polling connection 'qemu:///session'：unsupported operand type(s) for +=: 'NoneType' and 'int'
Traceback (most recent call last):
File "/usr/share/virt-manager/virtManager/engine.py", line 389, in _handle_tick_queue
conn.tick_from_engine(**kwargs)
File "/usr/share/virt-manager/virtManager/connection.py", line 1473, in tick_from_engine
raise e # pylint: disable=raising-bad-type
TypeError: unsupported operand type(s) for +=: 'NoneType' and 'int'
edit: its actually slightly different, but I think it may be part of the same issue
error: internal error: qemu unexpectedly closed the monitor: 2018-06-13T03:27:18.965770Z qemu-system-x86_64: -drive file=/dev/sda,format=raw,if=none,id=drive-virtio-disk1,cache=directsync,aio=native: Could not open '/dev/sda': Permission denied