Michal Privoznik <mprivozn@redhat.com> [2018-09-19, 11:45AM +0200]:
On 09/19/2018 11:17 AM, Bjoern Walk wrote:
Bjoern Walk <bwalk@linux.ibm.com> [2018-09-12, 01:17PM +0200]:
Michal Privoznik <mprivozn@redhat.com> [2018-09-12, 11:32AM +0200]:
Still seeing the same timeout. Is this expected behaviour?
Nope. I wonder if something has locked the path and forgot to unlock it (however, virtlockd should have unlocked all the paths owned by PID on connection close), or something is still holding the lock and connection opened.
I can reproduce on a freshly booted machine. There should be no rouge lock held anywhere.
Can you see the timeout even when you turn off the selinux driver (security_driver="none' in qemu.conf)? I tried to reproduce the issue
Yes, same issue.
yesterday and was unsuccessful. Do you have any steps to reproduce?
0. Host setup: # /usr/sbin/sestatus SELinux status: enabled SELinuxfs mount: /sys/fs/selinux SELinux root directory: /etc/selinux Loaded policy name: targeted Current mode: enforcing Mode from config file: enforcing Policy MLS status: enabled Policy deny_unknown status: allowed Memory protection checking: actual (secure) Max kernel policy version: 31 # grep -E "^[^#]" /etc/libvirt/qemu.conf lock_manager = "lockd" metadata_lock_manager = "lockd" 1. Define two domains, u1604-1 and u1604-2, using the same image, not shared: <domain type='kvm'> <name>u1604-1</name> <uuid>e49679de-eca9-4a72-8d1a-56f437541157</uuid> <memory unit='KiB'>524288</memory> <currentMemory unit='KiB'>524288</currentMemory> <vcpu placement='static'>2</vcpu> <os> <type arch='s390x' machine='s390-ccw-virtio-2.12'>hvm</type> <boot dev='hd'/> </os> <clock offset='utc'/> <on_poweroff>destroy</on_poweroff> <on_reboot>restart</on_reboot> <on_crash>preserve</on_crash> <devices> <emulator>/usr/bin/qemu-system-s390x</emulator> <disk type='file' device='disk'> <driver name='qemu' type='qcow2'/> <source file='/var/lib/libvirt/images/u1604.qcow2'/> <target dev='vda' bus='virtio'/> <address type='ccw' cssid='0xfe' ssid='0x0' devno='0x0000'/> </disk> <console type='pty'> <target type='sclp' port='0'/> </console> <memballoon model='virtio'> <address type='ccw' cssid='0xfe' ssid='0x0' devno='0x0001'/> </memballoon> <panic model='s390'/> </devices> </domain> 2. Start domain u1604-1: # ls -Z /var/lib/libvirt/images/u1604.qcow2 system_u:object_r:svirt_image_t:s0:c387,c937 /var/lib/libvirt/images/u1604.qcow2 3. Start domain u1604-2. 4. Result: the libvirtd hangs for 60 seconds after which the expected locking message appears. Security labels of the image are not changed: # virsh start u1604-2 error: Failed to start domain u1604-2 error: internal error: child reported: resource busy: Lockspace resource '/var/lib/libvirt/images/u1604.qcow2' is locked # ls -Z /var/lib/libvirt/images/u1604.qcow2 system_u:object_r:svirt_image_t:s0:c387,c937 /var/lib/libvirt/images/u1604.qcow2 Backtrace is the same I sent earlier. Let me know if you need more info or if anything is borked in my setup.
Michal