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.
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
(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.
The attached log file is the client log file. Please attach the debug log from libvirtd.
Created attachment 1262383 [details] test-v2v-i-ova.sh.log
Created attachment 1262384 [details] libvirtd.log (xz-compressed)
I re-enabled this test as somehow this has 'fixed itself' ... Hmmm, I don't really believe that bugs fix themselves.
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.
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