Bug 1809703

Summary: [Blocked] Use qemu-img info -U option to avoid locking error with virt-* tools
Product: Red Hat Enterprise Linux 8 Reporter: schandle
Component: libguestfsAssignee: Richard W.M. Jones <rjones>
Status: CLOSED CANTFIX QA Contact: YongkuiGuo <yoguo>
Severity: high Docs Contact:
Priority: low    
Version: 8.1CC: imomin, kkiwi, mkalinin, mvanderw, ptoscano, pveiga, rjones, tyan, tzheng, usurse, virt-maint, xchen, yoguo
Target Milestone: rcKeywords: Regression, Triaged
Target Release: 8.0   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2022-01-24 16:16:42 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: 1519242    
Bug Blocks: 1897024    

Description schandle 2020-03-03 17:40:39 UTC 
Description of problem:
libguiestfs tools are not working as they have in RHEL 7.x with the change of qemu-img now using the -U to varify a live image. 

When using tools like virt-df and the rest of the virt-* tools against a live VM, it is unable to access the backing file because of write lock

Version-Release number of selected component (if applicable):
libguestfs-1.38.4-14 
qemu-kvm-2.12.0-88
kernel-4.18.0-147.el8.x86_64

How reproducible:
100 %

Steps to Reproduce:
1. yum install '*guestf*'
2. start a KVM guest 
3. virt-df -d <domain_name>

Actual results:
~~~
# virt-df -d rhel-7
libguestfs: error: could not create appliance through libvirt.

Try running qemu directly without libvirt using this environment variable:
export LIBGUESTFS_BACKEND=direct

Original error from libvirt: internal error: process exited while connecting to monitor: arserial0,id=serial0 -chardev socket,id=charchannel0,path=/tmp/libguestfsMAjZPC/guestfsd.sock -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=org.libguestfs.channel.0 -object rng-random,id=objrng0,filename=/dev/urandom -device virtio-rng-pci,rng=objrng0,id=rng0,bus=pci.0,addr=0x4 -sandbox on,obsolete=deny,elevateprivileges=deny,spawn=deny,resourcecontrol=deny -msg timestamp=on
2020-03-03 17:29:46.520+0000: Domain id=3 is tainted: custom-argv
2020-03-03 17:29:46.520+0000: Domain id=3 is tainted: host-cpu
2020-03-03T17:29:46.590130Z qemu-kvm: -drive file=/tmp/libguestfsCUcrvw/overlay1.qcow2,format=qcow2,if=none,id=drive-scsi0-0-0-0,cache=unsafe: Could not open backing file: Failed to get shared "write" lock
Is another process using the image [/home/qemu/rhel-server-7.7-x86_64-kvm.qcow2]? [code=1 int1=-1]
~~~

Expected results:
When runnig the same in RHEL 7
~~~
[root@localhost ~]# virt-df -d rhel7.7
Filesystem                           1K-blocks       Used  Available  Use%
rhel7.7:/dev/sda1                      8181760    1738520    6443240   22%
~~~

Additional info:
The following commit is supposed to be included it
   https://github.com/libguestfs/libguestfs/commit/f00f920ad3b15ab8e9e8f201c16e7628b6b7b109
Comment 1 Pino Toscano 2020-03-16 16:13:13 UTC 
https://github.com/libguestfs/libguestfs/commit/f00f920ad3b15ab8e9e8f201c16e7628b6b7b109
This commit is present upstream starting from libguestfs 1.39.12, and thus it is already in the version of libguestfs in RHEL AV.
OTOH, the reported version indicate the libguestfs version used in the one from virt:rhel, hence reassigning.
Comment 6 Pino Toscano 2020-03-19 10:38:13 UTC 
Actually, this is slightly different than what was originally suggested.

While it is true that virt:rhel lacks that patch, it won't fix the issue, as it is a much bigger problem -- see bug 1519242 for the reason why the libvirt backend (used by default in RHEL) fails in the described scenario.

Because of this, fixing this will require fixing bug 1519242, which is definitely not a piece of cake.

As a workaround, the 'direct' libguestfs backend can be used -- for example:
  $ LIBGUESTFS_BACKEND=direct virt-df -d rhel-7
Comment 12 Richard W.M. Jones 2022-01-24 16:16:42 UTC 
This bug cannot be fixed without fixing libvirt.  There is
a workaround in comment 6 which can be used instead.  If the
workaround isn't adequate then you'll need to work with the
libvirt team to address bug 1519242.