Bug 1745618 - lockd + virsh snapshot-create-as does not unlock base file, blockcommit fails
Summary: lockd + virsh snapshot-create-as does not unlock base file, blockcommit fails
Keywords:
Status: CLOSED NEXTRELEASE
Alias: None
Product: Virtualization Tools
Classification: Community
Component: libvirt
Version: unspecified
Hardware: Unspecified
OS: Linux
unspecified
unspecified
Target Milestone: ---
Assignee: Peter Krempa
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2019-08-26 14:01 UTC by Daniel Weller
Modified: 2019-09-06 06:18 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-09-06 06:18:05 UTC
Embargoed:


Attachments (Terms of Use)

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.


Note You need to log in before you can comment on or make changes to this bug.