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 1431454

Summary: Cannot access backing file .. (as uid:4294967295, gid:4294967295): No such file or directory
Product: [Community] Virtualization Tools Reporter: Richard W.M. Jones <rjones>
Component: libvirtAssignee: Libvirt Maintainers <libvirt-maint>
Status: CLOSED WONTFIX QA Contact:
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: unspecifiedCC: libvirt-maint, pkrempa, ptoscano, rbalakri, rjones, tgolembi
Target Milestone: ---   
Target Release: ---   
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: 2017-03-27 13:36:08 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: 910269    
Attachments:
Description Flags
test-v2v-i-ova.sh.log
none
test-v2v-i-ova.sh.log
none
libvirtd.log (xz-compressed) none

Description Richard W.M. Jones 2017-03-12 18:51:08 UTC
Created attachment 1262260 [details]
test-v2v-i-ova.sh.log

Description of problem:

Running the v2v/test-v2v-i-ova.sh gives a nonsensical error
about the backing file:

Original error from libvirt: Cannot access backing file 
'test-v2v-i-ova.d/test-ova.ova' of storage file 
'/home/rjones/d/libguestfs/tmp/v2vovl6f0542.qcow2' (as uid:4294967295, 
gid:4294967295): No such file or directory [code=38 int1=2]

$ id
uid=1000(rjones) gid=1000(rjones) groups=1000(rjones),10(wheel),135(mock) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023

The uid/gid are completely wrong.

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

libvirt-3.1.0-1.fc27.x86_64

How reproducible:

100%

Steps to Reproduce:
1. In the libguestfs test suite, make -C v2v check

See the attached log for a lot more details.

Comment 1 Richard W.M. Jones 2017-03-12 18:53:51 UTC
I should probably note here:

(1) It's not being run as root.

(2) The directory is readable and permissions are normal:

$ ls -al v2v/test-v2v-i-ova.d
total 4016
drwxrwxr-x.  2 rjones rjones    4096 Mar 12 18:49 .
drwxrwxr-x. 17 rjones rjones   24576 Mar 12 18:53 ..
-rw-rw-r--.  1 rjones rjones 4075520 Mar 12 18:49 test-ova.ova

Comment 2 Richard W.M. Jones 2017-03-12 18:55:25 UTC
(In reply to Richard W.M. Jones from comment #0)
> Running the v2v/test-v2v-i-ova.sh gives a nonsensical error
> about the backing file:
> 
> Original error from libvirt: Cannot access backing file 
> 'test-v2v-i-ova.d/test-ova.ova' of storage file 
> '/home/rjones/d/libguestfs/tmp/v2vovl6f0542.qcow2' (as uid:4294967295, 
> gid:4294967295): No such file or directory [code=38 int1=2]
> 
> The uid/gid are completely wrong.

And the other point here is that the file *does* exist.

This worked in earlier versions of libvirt.

Comment 3 Peter Krempa 2017-03-13 07:13:33 UTC
The attached log file is the client log file. Please attach the debug log from libvirtd.

Comment 4 Richard W.M. Jones 2017-03-13 10:33:56 UTC
Created attachment 1262383 [details]
test-v2v-i-ova.sh.log

Comment 5 Richard W.M. Jones 2017-03-13 10:35:13 UTC
Created attachment 1262384 [details]
libvirtd.log (xz-compressed)

Comment 6 Richard W.M. Jones 2017-03-24 22:39:28 UTC
I re-enabled this test as somehow this has 'fixed itself' ...  Hmmm,
I don't really believe that bugs fix themselves.

Comment 7 Peter Krempa 2017-03-27 13:36:08 UTC
So the rather weird uid/gid reported is an artifact of using the session mode, since that does not initialize any uid/gid into the qemu config. We use -1 cast to uid_t to use the current ID but the error message does not reflect this. This is not the problem though.

The problem is that you attempt to use a relative image path with JSON protocol specification. Libvirt expects that anything looking like a protocol specification (which JSON is) is an absolute path.

 string={ "file": { "driver": "raw", "offset": 10752, "size": 4063232, "file": { "driver": "file", "filename": "test-v2v-i-ova.d/test-ova.ova" } } }

I'm not sure if libvirt wants to support a configuration like this at all. I'd suggest you use a proper relative name without the JSON protocol to do relative paths, or use absolute paths.

While your configuration can work with qemu, using relative paths may fail since they are relative to the current working directory of libvirtd.

Comment 8 Richard W.M. Jones 2017-03-27 16:44:13 UTC
At least that explains why the bug fixed itself.  It's because of
this change that I made:

https://github.com/libguestfs/libguestfs/commit/91b5fb3641c91ff4e4778879d4bc866089923c28