[0/2] block: JSON filenames and relative backing files

On Thu, Oct 23, 2014 at 04:56:13PM +0200, Max Reitz wrote:
> Sometimes, qemu does not have a filename to work with (it then generates
> a JSON filename), so it does not know which directory to use for a
> backing file specified by a relative filename.
> 
> In this case, qemu should not somehow try to append the backing file's
> name to the JSON object, but rather just print an error and bail out.
> 
> 
> Max Reitz (2):
>   block: JSON filenames and relative backing files
>   iotests: Add test for relative backing file names
> 
>  block.c                    | 19 +++++++---
>  block/qapi.c               |  7 +++-
>  include/block/block.h      |  2 +-
>  tests/qemu-iotests/110     | 87 ++++++++++++++++++++++++++++++++++++++++++++++
>  tests/qemu-iotests/110.out | 15 ++++++++
>  tests/qemu-iotests/group   |  1 +
>  6 files changed, 125 insertions(+), 6 deletions(-)
>  create mode 100755 tests/qemu-iotests/110
>  create mode 100644 tests/qemu-iotests/110.out

Unfortunately this breaks qemu-iotests check -vmdk 110 so I had to drop
the patches.

110 0s ... - output mismatch (see 110.out.bad)

On 2014-11-03 at 12:41, Stefan Hajnoczi wrote:
> On Thu, Oct 23, 2014 at 04:56:13PM +0200, Max Reitz wrote:
>> Sometimes, qemu does not have a filename to work with (it then generates
>> a JSON filename), so it does not know which directory to use for a
>> backing file specified by a relative filename.
>>
>> In this case, qemu should not somehow try to append the backing file's
>> name to the JSON object, but rather just print an error and bail out.
>>
>>
>> Max Reitz (2):
>>    block: JSON filenames and relative backing files
>>    iotests: Add test for relative backing file names
>>
>>   block.c                    | 19 +++++++---
>>   block/qapi.c               |  7 +++-
>>   include/block/block.h      |  2 +-
>>   tests/qemu-iotests/110     | 87 ++++++++++++++++++++++++++++++++++++++++++++++
>>   tests/qemu-iotests/110.out | 15 ++++++++
>>   tests/qemu-iotests/group   |  1 +
>>   6 files changed, 125 insertions(+), 6 deletions(-)
>>   create mode 100755 tests/qemu-iotests/110
>>   create mode 100644 tests/qemu-iotests/110.out
> Unfortunately this breaks qemu-iotests check -vmdk 110 so I had to drop
> the patches.
>
> 110 0s ... - output mismatch (see 110.out.bad)
> --- /home/stefanha/qemu/tests/qemu-iotests/110.out	2014-11-03 09:48:42.157955288 +0000
> +++ 110.out.bad	2014-11-03 10:11:59.469231898 +0000
> @@ -3,13 +3,26 @@
>   === Reconstructable filename ===
>   
>   Formatting 'TEST_DIR/t.IMGFMT.base', fmt=IMGFMT size=67108864
> +qemu-img: TEST_DIR/t.IMGFMT: Could not open 't.IMGFMT.base': No such file or directory
>   Formatting 'TEST_DIR/t.IMGFMT', fmt=IMGFMT size=67108864 backing_file='t.IMGFMT.base'
> -image: TEST_DIR/t.IMGFMT
> -file format: IMGFMT
> -virtual size: 64M (67108864 bytes)
> -backing file: t.IMGFMT.base (actual path: TEST_DIR/t.IMGFMT.base)
> +qemu-img: Could not open 'json:{'driver':'IMGFMT','file':{'driver':'file','filename':'TEST_DIR/t.IMGFMT'}}': Could not open 'TEST_DIR/t.IMGFMT': No such file or directory
>   
>   === Non-reconstructable filename ===
>   
> -qemu-img: Cannot use relative backing file names for 'json:{"driver": "IMGFMT", "file": {"set-state": [{"new_state": 42, "state": 0, "event": "read_aio"}], "image": {"driver": "file", "filename": "TEST_DIR/t.IMGFMT"}, "driver": "blkdebug"}}'
> +qemu-img: Could not open 'json:{
> +    'driver': 'IMGFMT',
> +    'file': {
> +        'driver': 'blkdebug',
> +        'image': {
> +            'driver': 'file',
> +            'filename': 'TEST_DIR/t.IMGFMT'
> +        },
> +        'set-state': [
> +            {
> +                'event': 'read_aio',
> +                'new_state': 42
> +            }
> +        ]
> +    }
> +}': Could not open 'TEST_DIR/t.IMGFMT': No such file or directory

Well, it doesn't break the test, the new test just doesn't work. The 
reason it doesn't work seems to be a bug in VMDK, as far as I can tell 
(although I don't know anything about VMDK, basically): In contrast to 
the rest of the block layer, it uses the backing file name directly, 
that is, relative to qemu's working directory, instead of relative to 
the image's directory.

I'll see whether I can fix that, and if I can't, I'll just send the v2 
with VMDK removed from the list of supported formats.

Max