Bug 1745618

Summary:	lockd + virsh snapshot-create-as does not unlock base file, blockcommit fails
Product:	[Community] Virtualization Tools	Reporter:	Daniel Weller <d.weller>
Component:	libvirt	Assignee:	Peter Krempa <pkrempa>
Status:	CLOSED NEXTRELEASE	QA Contact:
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	unspecified	CC:	libvirt-maint, pkrempa, tburke
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2019-09-06 06:18:05 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:

Description Daniel Weller 2019-08-26 14:01:22 UTC

Description of problem:
Live-snapshots/backup of running vms cant be committed back to base.
Lock of base-image seems not to be lifted

Version-Release number of selected component (if applicable):
virsh --version
5.0.0

How reproducible:
always

Steps to Reproduce:
Following the steps described in https://wiki.libvirt.org/page/Live-disk-backup-with-active-blockcommit
1. Create vm with qcow2 disk image
2. virsh snapshot-create-as --domain vm --name backup --quiesce --no-metadata --atomic --disk-only --diskspec vda,snapshot=external
3. do backup with base image
4. virsh blockcommit v vda --active --pivot --verbose

Actual results:
blockcommit fails, the disk image remains a chain.
error: resource busy: Lockspace resource '...' is locked

blockcommit works after reboot of vm

Expected results:
a single consolidated disk image

Additional info:
augtool -s set /files/etc/libvirt/qemu-lockd.conf/file_lockspace_dir "/kvm/images/locks"
augtool -s  set /files/etc/libvirt/qemu.conf/lock_manager lockd

Comment 1 Daniel Weller 2019-08-26 14:21:01 UTC

System is running CentOS 7 (7.6.1810)

# virsh snapshot-create-as --domain v --name backup --quiesce --no-metadata --atomic --disk-only --diskspec vda,snapshot=external
Domain snapshot backup created

# ls -l /kvm/images/locks
-rw-------. 1 root root 0 Aug 26 16:15 1e36b60940708425eefd7bfdf0279ee180e501cf30610cc8b662ae84554511a5
-rw-------. 1 root root 0 Aug 26 16:17 c35b05a3c2390ebdac8664c438644bc9f6bf7b7c170d969965b21e5815f1d79e

# virsh blockcommit v vda --active --pivot --verbose
error: resource busy: Lockspace resource '1e36b60940708425eefd7bfdf0279ee180e501cf30610cc8b662ae84554511a5' is locked

# virsh reboot v
Domain v is being rebooted

# virsh blockcommit v vda --active --pivot --verbose
error: resource busy: Lockspace resource '1e36b60940708425eefd7bfdf0279ee180e501cf30610cc8b662ae84554511a5' is locked

# virsh shutdown v
Domain v is being shutdown
# virsh start v
Domain v started

# virsh blockcommit v vda --active --pivot --verbose
Block commit: [100 %]
Successfully pivoted

Comment 2 Peter Krempa 2019-08-29 15:04:27 UTC

Patches 1 to 3 of https://www.redhat.com/archives/libvir-list/2019-August/msg01329.html fix this bug.

Comment 3 Peter Krempa 2019-09-06 06:18:05 UTC

Fixed upstream:

commit e0720fda12d2e7d72277cc90e90e7497dd834b78
Author: Peter Krempa <pkrempa>
Date:   Wed Aug 28 09:30:33 2019 +0200

    qemu: snapshot: Fix image lock handling when taking a snapshot
    
    When we take a snapshot we must properly remove our locking
    infrastructure locks. This was broken by commit 3817fa10c4ad9 which
    attempted to properly track the readonly state for the image as the
    locking code was executed after this change. Since we forced the image
    which was locked as read-write to read-only prior to unlocking it the
    write lock was not dropped.
    
    Fix it by moving the locking code prior to modifying the readonly flag.