aboutsummaryrefslogtreecommitdiff
path: root/tests/qemu-iotests/210.out
AgeCommit message (Collapse)Author
2019-04-30qemu-img: Saner printing of large file sizesEric Blake
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-02-25iotests.py: s/_/-/g on keys in qmp_log()Max Reitz
This follows what qmp() does, so the output will correspond to the actual QMP command. Signed-off-by: Max Reitz <mreitz@redhat.com> Message-id: 20190210145736.1486-11-mreitz@redhat.com Signed-off-by: Max Reitz <mreitz@redhat.com>
2018-10-30iotests: Unify log outputs between Python 2 and 3Max Reitz
When dumping an object into the log, there are differences between Python 2 and 3. First, unicode strings are prefixed by 'u' in Python 2 (they are no longer in 3, because unicode strings are the default there). Second, the order of keys in dicts may differ. Third, especially long numbers are longs in Python 2 and thus get an 'L' suffix, which does not happen in Python 3. We can get around all of these differences by dumping objects (lists and dicts) in a language-independent format, namely JSON. The JSON generator even allows emitting dicts with their keys sorted alphabetically. This changes the output of all tests that use these logging functions (dict keys are ordered now, strings in dicts are now enclosed in double quotes instead of single quotes, the 'L' suffix of large integers is dropped, and "true" and "false" are now in lower case). The quote change necessitates a small change to a filter used in test 207. Suggested-by: Eduardo Habkost <ehabkost@redhat.com> Signed-off-by: Max Reitz <mreitz@redhat.com> Reviewed-by: Cleber Rosa <crosa@redhat.com> Message-Id: <20181022135307.14398-10-mreitz@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2018-05-30block/create: Mark blockdev-create stableKevin Wolf
We're ready to declare the blockdev-create job stable. This renames the corresponding QMP command from x-blockdev-create to blockdev-create. Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com> Reviewed-by: Jeff Cody <jcody@redhat.com>
2018-05-30qemu-iotests: Rewrite 210 for blockdev-create jobKevin Wolf
This rewrites the test case 210 to work with the new x-blockdev-create job rather than the old synchronous version of the command. All of the test cases stay the same as before, but in order to be able to implement proper job handling, the test case is rewritten in Python. Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com> Reviewed-by: Jeff Cody <jcody@redhat.com>
2018-03-26qemu-iotests: Test invalid resize on luksKevin Wolf
This tests that the .bdrv_truncate implementation for luks doesn't crash for invalid image sizes. Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com>
2018-03-19qemu-iotests: Test luks QMP image creationKevin Wolf
Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>