Bug 1191901
| Summary: | live external disk-only snapshot deadlocks with lock manager | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | Yang Yang <yanyang> | ||||
| Component: | libvirt | Assignee: | Peter Krempa <pkrempa> | ||||
| Status: | CLOSED ERRATA | QA Contact: | Han Han <hhan> | ||||
| Severity: | medium | Docs Contact: | |||||
| Priority: | medium | ||||||
| Version: | 7.1 | CC: | dyuan, hhan, jdenemar, leuffen, mzhan, piotr.rybicki, pkrempa, rbalakri, w90p710, xuzhang, yisun | ||||
| Target Milestone: | rc | ||||||
| Target Release: | --- | ||||||
| Hardware: | x86_64 | ||||||
| OS: | Linux | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | libvirt-3.0.0-1.el7 | Doc Type: | If docs needed, set a value | ||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2017-08-01 17:06:41 UTC | Type: | Bug | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Bug Depends On: | |||||||
| Bug Blocks: | 1288337, 1304579, 1401400 | ||||||
| Attachments: |
|
||||||
|
Description
Yang Yang
2015-02-12 08:24:45 UTC
+1 to this bug report. Bug stil exists in libvirt-1.2.19 The bug can also be reproduced on sanlock.
Version:
sanlock-3.2.4-1.el7.x86_64
qemu-kvm-rhev-2.3.0-31.el7.x86_64
libvirt-1.2.17-13.el7.x86_64
Steps:
1. grep lock_ /etc/libvirt/qemu.conf
lock_manager = "sanlock"
# vim /etc/libvirt/qemu-sanlock.conf
auto_disk_leases = 1
disk_lease_dir = "/var/lib/libvirt/sanlock"
host_id = 1
user = "sanlock"
group = "sanlock"
# vim /etc/sysconfig/sanlock
SANLOCKOPTS="-w 0"
2. Restart sanlock and libvirtd
# systemctl restart sanlcok; systemctl restart libvirtd
3. Prepare a guest n1 like this:
...
<disk type='file' device='disk'>
<driver name='qemu' type='qcow2'/>
<source file='/var/lib/libvirt/images/n1.qcow2'/>
<target dev='vda' bus='virtio'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x0'/>
</disk>
...
Create external snapshots:
# for i in s{1..3} ;do virsh snapshot-create-as n1 $i --disk-only --diskspec vda,file=/tmp/n1.$i;sleep 2;done
Libvirtd hang when creating external disk only snapshot. And snap file created.
# ll /tmp/n1.s1 -SH
-rw-------. 1 qemu qemu 4.7M Nov 20 15:40 /tmp/n1.s1
*** Bug 1272384 has been marked as a duplicate of this bug. *** Same here. Any suggestions and/or workarounds (different from disabling locking at all)? Hi, Peter, the bug seems fixed on libvirt-2.0.0-10.el7_3.3.x86_64 since I cannot reproduce it by both comment0 and comment3. Pls check if the patches of BZ1406765 can fix this bug. Thanks. There are a few more cases that need fixing. Notably with automatic disk locking. I've posted a series to fix some of them https://www.redhat.com/archives/libvir-list/2016-December/msg00809.html commit f61e40610d790836f3af2393ae7d77843f03f378
Author: Peter Krempa <pkrempa>
Date: Fri Dec 16 15:45:26 2016 +0100
qemu: snapshot: Properly handle image locking
Images that became the backing chain of the current image due to the
snapshot need to be unlocked in the lock manager. Also if qemu was
paused during the snapshot the current top level images need to be
released until qemu is resumed so that they can be acquired properly.
Verified on libvirt-3.2.0-2.el7.x86_64 sanlock-3.4.0-1.el7.x86_64 1. Set virtlockd environment as comment0 2. Start VM and create snapshots 3. Set sanlock environment as comment3 4. Start VM and create snapshots Detailed steps: 1. For virtlocked + DOM=V [17/1034] + prep_virtlockd + augtool set /files/etc/libvirt/qemu.conf/lock_manager lockd Saved 1 file(s) + augtool set /files/etc/libvirt/qemu-lockd.conf/auto_disk_leases 1 Saved 1 file(s) + augtool set /files/etc/libvirt/qemu-lockd.conf/require_lease_for_disks 1 Saved 1 file(s) + augtool set /files/etc/libvirt/qemu-lockd.conf/file_lockspace_dir /var/lib/libvirt/lockd/files Saved 1 file(s) + systemctl restart virtlockd + systemctl restart libvirtd + virsh start V Domain V started + sleep 5 + for i in 's{1..5}' + virsh snapshot-create-as V s1 --disk-only Domain snapshot s1 created + for i in 's{1..5}' + virsh snapshot-create-as V s2 --disk-only Domain snapshot s2 created + for i in 's{1..5}' + virsh snapshot-create-as V s3 --disk-only Domain snapshot s3 created + for i in 's{1..5}' + virsh snapshot-create-as V s4 --disk-only Domain snapshot s4 created + for i in 's{1..5}' + virsh snapshot-create-as V s5 --disk-only Domain snapshot s5 created 2. For sanlock: + prep_sanlock + augtool set /files/etc/libvirt/qemu.conf/lock_manager sanlock Saved 1 file(s) + augtool set /files/etc/libvirt/qemu-sanlock.conf/auto_disk_leases 1 Saved 1 file(s) + augtool set /files/etc/libvirt/qemu-sanlock.conf/host_id 1 Saved 1 file(s) + augtool set /files/etc/libvirt/qemu-sanlock.conf/disk_lease_dir /var/lib/libvirt/sanlock Saved 1 file(s) + augtool set /files/etc/libvirt/qemu-sanlock.conf/user sanlock Saved 1 file(s) + augtool set /files/etc/libvirt/qemu-sanlock.conf/group sanlock Saved 1 file(s) + systemctl restart wdmd Job for wdmd.service failed because a timeout was exceeded. See "systemctl status wdmd.service" and "journalctl -xe" for details. + systemctl restart sanlock + systemctl restart libvirtd + '[' 0 -ne 0 ']' + virsh start V Domain V started + sleep 5 + for i in 's{1..5}' + virsh snapshot-create-as V s1 --disk-only Domain snapshot s1 created + for i in 's{1..5}' + virsh snapshot-create-as V s2 --disk-only Domain snapshot s2 created + for i in 's{1..5}' + virsh snapshot-create-as V s3 --disk-only Domain snapshot s3 created + for i in 's{1..5}' + virsh snapshot-create-as V s4 --disk-only Domain snapshot s4 created + for i in 's{1..5}' + virsh snapshot-create-as V s5 --disk-only Domain snapshot s5 created Snapshots created. No deadlock. Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHEA-2017:1846 Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHEA-2017:1846 Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHEA-2017:1846 |