OpenE2K/qemu-e2k
13
4
Fork 0
Code Issues 4 Pull Requests Projects 2 Releases Activity
ffbd2dbd8e
qemu-e2k/tests/qemu-iotests/110.out

30 lines
933 B
Plaintext
Raw Normal View History

iotests: Add test for relative backing file names Sometimes, qemu does not have a filename to work with, so it does not know which directory to use for a backing file specified by a relative filename. Add a test which tests that qemu exits with an appropriate error message. Additionally, add a test for qemu-img create with a backing filename relative to the backed image's base directory while omitting the image size. Signed-off-by: Max Reitz <mreitz@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Reviewed-by: Fam Zheng <famz@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2014-11-26 17:20:29 +01:00
QA output created by 110
=== Reconstructable filename ===
Formatting 'TEST_DIR/t.IMGFMT.base', fmt=IMGFMT size=67108864
iotests: Specify explicit backing format where sensible There are many existing qcow2 images that specify a backing file but no format. This has been the source of CVEs in the past, but has become more prominent of a problem now that libvirt has switched to -blockdev. With older -drive, at least the probing was always done by qemu (so the only risk of a changed format between successive boots of a guest was if qemu was upgraded and probed differently). But with newer -blockdev, libvirt must specify a format; if libvirt guesses raw where the image was formatted, this results in data corruption visible to the guest; conversely, if libvirt guesses qcow2 where qemu was using raw, this can result in potential security holes, so modern libvirt instead refuses to use images without explicit backing format. The change in libvirt to reject images without explicit backing format has pointed out that a number of tools have been far too reliant on probing in the past. It's time to set a better example in our own iotests of properly setting this parameter. iotest calls to create, rebase, and convert are all impacted to some degree. It's a bit annoying that we are inconsistent on command line - while all of those accept -o backing_file=...,backing_fmt=..., the shortcuts are different: create and rebase have -b and -F, while convert has -B but no -F. (amend has no shortcuts, but the previous patch just deprecated the use of amend to change backing chains). Signed-off-by: Eric Blake <eblake@redhat.com> Message-Id: <20200706203954.341758-9-eblake@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2020-07-06 22:39:52 +02:00
Formatting 'TEST_DIR/t.IMGFMT', fmt=IMGFMT size=67108864 backing_file=t.IMGFMT.base backing_fmt=IMGFMT
iotests: Add test for relative backing file names Sometimes, qemu does not have a filename to work with, so it does not know which directory to use for a backing file specified by a relative filename. Add a test which tests that qemu exits with an appropriate error message. Additionally, add a test for qemu-img create with a backing filename relative to the backed image's base directory while omitting the image size. Signed-off-by: Max Reitz <mreitz@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Reviewed-by: Fam Zheng <famz@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2014-11-26 17:20:29 +01:00
image: TEST_DIR/t.IMGFMT
file format: IMGFMT
qemu-img: Saner printing of large file sizes Disk sizes close to INT64_MAX cause overflow, for some pretty ridiculous output: $ ./nbdkit -U - memory size=$((2**63 - 512)) --run 'qemu-img info $nbd' image: nbd+unix://?socket=/tmp/nbdkitHSAzNz/socket file format: raw virtual size: -8388607T (9223372036854775296 bytes) disk size: unavailable But there's no reason to have two separate implementations of integer to human-readable abbreviation, where one has overflow and stops at 'T', while the other avoids overflow and goes all the way to 'E'. With this patch, the output now claims 8EiB instead of -8388607T, which really is the correct rounding of largest file size supported by qemu (we could go 511 bytes larger if we used byte-accurate sizing instead of rounding up to the next sector boundary, but that wouldn't change the human-readable result). Quite a few iotests need updates to expected output to match. Reported-by: Richard W.M. Jones <rjones@redhat.com> Signed-off-by: Eric Blake <eblake@redhat.com> Tested-by: Richard W.M. Jones <rjones@redhat.com> Reviewed-by: Alberto Garcia <berto@igalia.com> Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com> Tested-by: Max Reitz <mreitz@redhat.com>
2019-04-17 19:11:01 +02:00
virtual size: 64 MiB (67108864 bytes)
iotests: Add test for relative backing file names Sometimes, qemu does not have a filename to work with, so it does not know which directory to use for a backing file specified by a relative filename. Add a test which tests that qemu exits with an appropriate error message. Additionally, add a test for qemu-img create with a backing filename relative to the backed image's base directory while omitting the image size. Signed-off-by: Max Reitz <mreitz@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Reviewed-by: Fam Zheng <famz@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2014-11-26 17:20:29 +01:00
backing file: t.IMGFMT.base (actual path: TEST_DIR/t.IMGFMT.base)
=== Non-reconstructable filename ===
iotests: Make 110 work with data_file The only difference is that the json:{} filename of the image looks different. We actually do not care about that filename in this test, we are only interested in (1) that there is a json:{} filename, and (2) whether the backing filename can be constructed. So just filter out the json:{} data, thus making this test pass both with and without data_file. Signed-off-by: Max Reitz <mreitz@redhat.com> Reviewed-by: Maxim Levitsky <mlevitsk@redhat.com> Message-id: 20191107163708.833192-19-mreitz@redhat.com Signed-off-by: Max Reitz <mreitz@redhat.com>
2019-11-07 17:37:04 +01:00
image: json:{ /* filtered */ }
block/qapi: allow best-effort query For more complex BDS trees that can be created under normal circumstances, we lose the ability to issue query commands because of our inability to re-construct the absolute filename. Instead, omit this field when it is a problem and present as much information as we can. This will change the expected output in iotest 110, where we will now see a json filename and the lack of an absolute filename instead of an error. Signed-off-by: John Snow <jsnow@redhat.com> Message-id: 1450122916-4706-6-git-send-email-jsnow@redhat.com Reviewed-by: Max Reitz <mreitz@redhat.com> Signed-off-by: Max Reitz <mreitz@redhat.com>
2015-12-14 20:55:16 +01:00
file format: IMGFMT
qemu-img: Saner printing of large file sizes Disk sizes close to INT64_MAX cause overflow, for some pretty ridiculous output: $ ./nbdkit -U - memory size=$((2**63 - 512)) --run 'qemu-img info $nbd' image: nbd+unix://?socket=/tmp/nbdkitHSAzNz/socket file format: raw virtual size: -8388607T (9223372036854775296 bytes) disk size: unavailable But there's no reason to have two separate implementations of integer to human-readable abbreviation, where one has overflow and stops at 'T', while the other avoids overflow and goes all the way to 'E'. With this patch, the output now claims 8EiB instead of -8388607T, which really is the correct rounding of largest file size supported by qemu (we could go 511 bytes larger if we used byte-accurate sizing instead of rounding up to the next sector boundary, but that wouldn't change the human-readable result). Quite a few iotests need updates to expected output to match. Reported-by: Richard W.M. Jones <rjones@redhat.com> Signed-off-by: Eric Blake <eblake@redhat.com> Tested-by: Richard W.M. Jones <rjones@redhat.com> Reviewed-by: Alberto Garcia <berto@igalia.com> Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com> Tested-by: Max Reitz <mreitz@redhat.com>
2019-04-17 19:11:01 +02:00
virtual size: 64 MiB (67108864 bytes)
block: Use bdrv_dirname() for relative filenames bdrv_get_full_backing_filename_from_filename() breaks down when it comes to JSON filenames. Using bdrv_dirname() as the basis is better because since we have BDS, we can descend through the BDS tree to the protocol layer, which gives us a greater probability of finding a non-JSON name; also, bdrv_dirname() is more correct as it allows block drivers to override the generation of that directory name in a protocol-specific way. We still need to keep bdrv_get_full_backing_filename_from_filename(), though, because it has valid callers which need it during image creation when no BDS is available yet. This makes a test case in qemu-iotest 110, which was supposed to fail, work. That is actually good, but we need to change the reference output (and the comment in 110) accordingly. Signed-off-by: Max Reitz <mreitz@redhat.com> Reviewed-by: Alberto Garcia <berto@igalia.com> Message-id: 20190201192935.18394-20-mreitz@redhat.com Signed-off-by: Max Reitz <mreitz@redhat.com>
2019-02-01 20:29:23 +01:00
backing file: t.IMGFMT.base (actual path: TEST_DIR/t.IMGFMT.base)
iotests: Add test for relative backing file names Sometimes, qemu does not have a filename to work with, so it does not know which directory to use for a backing file specified by a relative filename. Add a test which tests that qemu exits with an appropriate error message. Additionally, add a test for qemu-img create with a backing filename relative to the backed image's base directory while omitting the image size. Signed-off-by: Max Reitz <mreitz@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Reviewed-by: Fam Zheng <famz@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2014-11-26 17:20:29 +01:00
=== Backing name is always relative to the backed image ===
iotests: Specify explicit backing format where sensible There are many existing qcow2 images that specify a backing file but no format. This has been the source of CVEs in the past, but has become more prominent of a problem now that libvirt has switched to -blockdev. With older -drive, at least the probing was always done by qemu (so the only risk of a changed format between successive boots of a guest was if qemu was upgraded and probed differently). But with newer -blockdev, libvirt must specify a format; if libvirt guesses raw where the image was formatted, this results in data corruption visible to the guest; conversely, if libvirt guesses qcow2 where qemu was using raw, this can result in potential security holes, so modern libvirt instead refuses to use images without explicit backing format. The change in libvirt to reject images without explicit backing format has pointed out that a number of tools have been far too reliant on probing in the past. It's time to set a better example in our own iotests of properly setting this parameter. iotest calls to create, rebase, and convert are all impacted to some degree. It's a bit annoying that we are inconsistent on command line - while all of those accept -o backing_file=...,backing_fmt=..., the shortcuts are different: create and rebase have -b and -F, while convert has -B but no -F. (amend has no shortcuts, but the previous patch just deprecated the use of amend to change backing chains). Signed-off-by: Eric Blake <eblake@redhat.com> Message-Id: <20200706203954.341758-9-eblake@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2020-07-06 22:39:52 +02:00
Formatting 'TEST_DIR/t.IMGFMT', fmt=IMGFMT size=67108864 backing_file=t.IMGFMT.base backing_fmt=IMGFMT
iotests: Add quorum case to test 110 Test 110 tests relative backing filenames for complex BDS trees. Now that the originally supposedly failing test passes, let us add a new failing test: Quorum can never work automatically (without detecting whether all child nodes have the same base directory, but that would be rather inconsistent behavior). Signed-off-by: Max Reitz <mreitz@redhat.com> Reviewed-by: Alberto Garcia <berto@igalia.com> Message-id: 20190201192935.18394-21-mreitz@redhat.com Signed-off-by: Max Reitz <mreitz@redhat.com>
2019-02-01 20:29:24 +01:00
=== Nodes without a common directory ===
iotests: Make 110 work with data_file The only difference is that the json:{} filename of the image looks different. We actually do not care about that filename in this test, we are only interested in (1) that there is a json:{} filename, and (2) whether the backing filename can be constructed. So just filter out the json:{} data, thus making this test pass both with and without data_file. Signed-off-by: Max Reitz <mreitz@redhat.com> Reviewed-by: Maxim Levitsky <mlevitsk@redhat.com> Message-id: 20191107163708.833192-19-mreitz@redhat.com Signed-off-by: Max Reitz <mreitz@redhat.com>
2019-11-07 17:37:04 +01:00
image: json:{ /* filtered */ }
iotests: Add quorum case to test 110 Test 110 tests relative backing filenames for complex BDS trees. Now that the originally supposedly failing test passes, let us add a new failing test: Quorum can never work automatically (without detecting whether all child nodes have the same base directory, but that would be rather inconsistent behavior). Signed-off-by: Max Reitz <mreitz@redhat.com> Reviewed-by: Alberto Garcia <berto@igalia.com> Message-id: 20190201192935.18394-21-mreitz@redhat.com Signed-off-by: Max Reitz <mreitz@redhat.com>
2019-02-01 20:29:24 +01:00
file format: IMGFMT
qemu-img: Saner printing of large file sizes Disk sizes close to INT64_MAX cause overflow, for some pretty ridiculous output: $ ./nbdkit -U - memory size=$((2**63 - 512)) --run 'qemu-img info $nbd' image: nbd+unix://?socket=/tmp/nbdkitHSAzNz/socket file format: raw virtual size: -8388607T (9223372036854775296 bytes) disk size: unavailable But there's no reason to have two separate implementations of integer to human-readable abbreviation, where one has overflow and stops at 'T', while the other avoids overflow and goes all the way to 'E'. With this patch, the output now claims 8EiB instead of -8388607T, which really is the correct rounding of largest file size supported by qemu (we could go 511 bytes larger if we used byte-accurate sizing instead of rounding up to the next sector boundary, but that wouldn't change the human-readable result). Quite a few iotests need updates to expected output to match. Reported-by: Richard W.M. Jones <rjones@redhat.com> Signed-off-by: Eric Blake <eblake@redhat.com> Tested-by: Richard W.M. Jones <rjones@redhat.com> Reviewed-by: Alberto Garcia <berto@igalia.com> Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com> Tested-by: Max Reitz <mreitz@redhat.com>
2019-04-17 19:11:01 +02:00
virtual size: 64 MiB (67108864 bytes)
iotests: Add quorum case to test 110 Test 110 tests relative backing filenames for complex BDS trees. Now that the originally supposedly failing test passes, let us add a new failing test: Quorum can never work automatically (without detecting whether all child nodes have the same base directory, but that would be rather inconsistent behavior). Signed-off-by: Max Reitz <mreitz@redhat.com> Reviewed-by: Alberto Garcia <berto@igalia.com> Message-id: 20190201192935.18394-21-mreitz@redhat.com Signed-off-by: Max Reitz <mreitz@redhat.com>
2019-02-01 20:29:24 +01:00
backing file: t.IMGFMT.base (cannot determine actual path)
iotests: Add test for relative backing file names Sometimes, qemu does not have a filename to work with, so it does not know which directory to use for a backing file specified by a relative filename. Add a test which tests that qemu exits with an appropriate error message. Additionally, add a test for qemu-img create with a backing filename relative to the backed image's base directory while omitting the image size. Signed-off-by: Max Reitz <mreitz@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Reviewed-by: Fam Zheng <famz@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2014-11-26 17:20:29 +01:00
*** done
Reference in New Issue Copy Permalink