Michal Privoznik <mprivozn(a)redhat.com> [2018-09-19, 11:45AM +0200]:
On 09/19/2018 11:17 AM, Bjoern Walk wrote:
> Bjoern Walk <bwalk(a)linux.ibm.com> [2018-09-12, 01:17PM +0200]:
>> Michal Privoznik <mprivozn(a)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