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
Task Type Bug Report
Category Upstream Bugs
Status Closed
Assigned To Christian Rebischke (Shibumi)
Architecture All
Severity High
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 8
Private No

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
Comment by Giancarlo Razzolini (grazzolini) - Wednesday, 06 June 2018, 17:54 GMT
Are you sure you are running arch linux? nobody is uid 99 and the 992 group is the libvirt one. kvm group on arch has gid 78.
Comment by loqs (loqs) - Wednesday, 06 June 2018, 18:51 GMT
@grazzolini depends on which version of filesystem was used during the initial installation if kvm was assigned 78 or the first highest avaiable ID pair below 1000
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#54943  and the entries added or not to the tmpfiles snippet.
Comment by Giancarlo Razzolini (grazzolini) - Wednesday, 06 June 2018, 19:36 GMT
Ah, I knew this had something to do with that bug. Regardless, I was not affected by this issue. One question though, why are you using sudo virsh and not using polkit to give your user proper access to libvirt?
Comment by loqs (loqs) - Wednesday, 06 June 2018, 20:29 GMT
kmahyyg can you bisect libvirt between 4.3.0 and 4.4.0 and find which commit triggers the issue?
Comment by Patrick Young (kmahyyg) - Thursday, 07 June 2018, 00:24 GMT
@grazzolini I'll upload a code snippet soon. like @loqs said, that's it. I usually just start up the VM in virt-manager, virt-manager reported the same issue.

@loqs Sorry, I don't have much time for that now. I have an important exam to be prepared these days.

Comment by Patrick Young (kmahyyg) - Thursday, 07 June 2018, 00:36 GMT
@grazzolini See screenshot.
Comment by Giancarlo Razzolini (grazzolini) - Thursday, 07 June 2018, 03:41 GMT
Yes, you can have these uid's/gid's on arch, my bad. Even though I was not affected by this issue, I found another one: https://bugs.archlinux.org/task/58903. It looks there are some issues with 4.4.0 indeed.
Comment by loqs (loqs) - Thursday, 07 June 2018, 10:34 GMT
@grazzolini  FS#58903  is explained by https://bugs.archlinux.org/task/58375#comment169085 the broken implementation of  FS#56677 
Comment by Uwe Sauter (UweSauter) - Thursday, 07 June 2018, 20:24 GMT
I'd like to add two scenarios that stopped working for me.

1) 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.
Comment by loqs (loqs) - Thursday, 07 June 2018, 20:44 GMT
PKGBUILD adjusted to allow for bisection without triggering make calling bootstrap calling autoconf calling configure with no options etc
   PKGBUILD (6.3 KiB)
Comment by Giancarlo Razzolini (grazzolini) - Thursday, 07 June 2018, 20:51 GMT
I don't think there's a need to have a split package. Just make libvirt depend on glusterfs and move on. I have done some research today, and I was not able to find anything against depending directly on it.
Comment by loqs (loqs) - Thursday, 07 June 2018, 20:58 GMT
Why not drop glusterfs all together gluster storage support has been broken since 4.1.0-1 and no one has noticed until  FS#58375  including the original feature requester.
But that really is  FS#58903  unless you think these bugs share a common cause.
Comment by loqs (loqs) - Thursday, 07 June 2018, 22:51 GMT
@grazzolini as there are now fixes in the kernel and libvirt packages as well as CPU implementation fixes for some AMD families
will you cherry pick the fixes for  FS#58700  so QEMU/KVM guests on AMD could use the kernel mitigations?
Comment by Patrick Young (kmahyyg) - Friday, 08 June 2018, 12:19 GMT
install glusterfs. Problem fixed.

Maybe you should drop glusterfs support.
Comment by loqs (loqs) - Friday, 08 June 2018, 12:43 GMT
@kmahyyg if you remove glusterfs and then delete /usr/lib/libvirt/storage-file/libvirt_storage_file_gluster.so does the issue reappear?
Comment by Patrick Young (kmahyyg) - Friday, 08 June 2018, 14:06 GMT
@loqs Rewrite my qemu.conf to the default one and removed the package&library file you said. The issue won't appear.
Comment by Christian Rebischke (Shibumi) - Friday, 08 June 2018, 14:49 GMT
I have merged libvirt with libvirt-glusterfs.. can the bug report opener confirm that 4.4.0-2 fixes his issues?
Comment by loqs (loqs) - Friday, 08 June 2018, 15:36 GMT
Minor issues you left
# "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
Comment by Patrick Young (kmahyyg) - Friday, 08 June 2018, 15:51 GMT
4.4.0-2 fixed but with glusterfs installed.
Comment by Patrick Young (kmahyyg) - Sunday, 10 June 2018, 08:44 GMT
New bug arose since 4.4.0-2:

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'
Comment by Christian Rebischke (Shibumi) - Sunday, 10 June 2018, 15:11 GMT
The latter one looks like a bug in virt-manager
Comment by Sam Voss (smvoss) - Wednesday, 13 June 2018, 03:28 GMT
Still seeing this bug as of 4.4.0-3, with all packages up to date

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
Comment by Jolan Luff (jolan) - Tuesday, 14 August 2018, 22:54 GMT
Seems to have been fixed in 4.5.0. 4.6.0 works for me too.
Comment by Marcus Heese (mheese) - Wednesday, 15 August 2018, 00:11 GMT
I can also confirm this as resolved since 4.5.0 - and 4.6.0 is also fine.

Loading...