Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 1809703 - [Blocked] Use qemu-img info -U option to avoid locking error with virt-* tools
Summary: [Blocked] Use qemu-img info -U option to avoid locking error with virt-* tools
Keywords:
Status: NEW
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: libguestfs
Version: 8.1
Hardware: Unspecified
OS: Unspecified
unspecified
high
Target Milestone: rc
: 8.0
Assignee: Richard W.M. Jones
QA Contact: YongkuiGuo
URL:
Whiteboard:
Depends On: 1519242
Blocks: 1897024
TreeView+ depends on / blocked
 
Reported: 2020-03-03 17:40 UTC by schandle
Modified: 2023-03-10 08:30 UTC (History)
10 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed:
Type: Bug
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Issue Tracker TP-861 0 None None None 2023-03-10 08:30:46 UTC
Red Hat Knowledge Base (Solution) 4870801 0 None None None 2020-03-03 17:55:33 UTC

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
Note You need to log in before you can comment on or make changes to this bug.