mirrors/qemu
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
1ff788db97
qemu/tests/qemu-iotests/070.out

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

28 lines
1.0 KiB
Plaintext
Raw Normal View History

block: vhdx qemu-iotest - log replay of data sector This tests the replay of a data sector in a VHDX image file. The image file is a 10G dynamic image, with 4MB block size. The image was created with qemu-img, and the log left unplayed by modification of the vhdx image format driver. It was verified under both QEMU and Hyper-V that the image file, post log replay, matched. Signed-off-by: Jeff Cody <jcody@redhat.com> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2013-10-30 18:44:56 +04:00
QA output created by 070
=== Verify open image read-only fails, due to dirty log ===
tests/qemu-iotests: Fix output of qemu-io related tests One of the recent commits changed the way qemu-io prints out its errors and warnings - they are now prefixed with the program name. We've got to adapt the iotests accordingly to prevent that they are failing. Fixes: 99e98d7c9fc1a1639fad ("qemu-io: Use error_[gs]et_progname()") Signed-off-by: Thomas Huth <thuth@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2019-04-28 18:54:44 +03:00
qemu-io: can't open device TEST_DIR/iotest-dirtylog-10G-4M.vhdx: VHDX image file 'TEST_DIR/iotest-dirtylog-10G-4M.vhdx' opened read-only, but contains a log that needs to be replayed
vhdx: Fix "log that needs to be replayed" error message The arguments of error_setg_errno() should yield a short error string without newlines. Here, we try to append additional help to the error message by embedding newlines in the error string. That's nice, but it's doesn't play nicely with the errno part. tests/qemu-iotests/070.out shows the resulting mess: can't open device TEST_DIR/iotest-dirtylog-10G-4M.vhdx: VHDX image file 'TEST_DIR/iotest-dirtylog-10G-4M.vhdx' opened read-only, but contains a log that needs to be replayed. To replay the log, execute: qemu-img check -r all 'TEST_DIR/iotest-dirtylog-10G-4M.vhdx': Operation not permitted Switch to error_setg() and error_append_hint(). Result: can't open device TEST_DIR/iotest-dirtylog-10G-4M.vhdx: VHDX image file 'TEST_DIR/iotest-dirtylog-10G-4M.vhdx' opened read-only, but contains a log that needs to be replayed To replay the log, run: qemu-img check -r all 'TEST_DIR/iotest-dirtylog-10G-4M.vhdx' Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Message-Id: <1450452927-8346-21-git-send-email-armbru@redhat.com>
2015-12-18 18:35:23 +03:00
To replay the log, run:
qemu-img check -r all 'TEST_DIR/iotest-dirtylog-10G-4M.vhdx'
block: vhdx qemu-iotest - log replay of data sector This tests the replay of a data sector in a VHDX image file. The image file is a 10G dynamic image, with 4MB block size. The image was created with qemu-img, and the log left unplayed by modification of the vhdx image format driver. It was verified under both QEMU and Hyper-V that the image file, post log replay, matched. Signed-off-by: Jeff Cody <jcody@redhat.com> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2013-10-30 18:44:56 +04:00
=== Verify open image replays log ===
read 18874368/18874368 bytes at offset 0
18 MiB, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
block: qemu-iotests - add vhdx log replay tests for qemu-img VHDX logs can now be replayed via 'qemu-img check -r all'. Add tests to verify that the log replay is successful when using qemu-img. Signed-off-by: Jeff Cody <jcody@redhat.com> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2014-02-13 01:30:53 +04:00
=== Verify qemu-img check -r all replays log ===
The following inconsistencies were found and repaired:
0 leaked clusters
1 corruptions
Double checking the fixed image now...
No errors were found on the image.
=== Verify open image read-only succeeds after log replay ===
read 18874368/18874368 bytes at offset 0
18 MiB, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
block: add test for vhdx image created by Disk2VHD This adds a test for VHDX images created by Microsoft's tool, Disk2VHD. VHDX images created by this tool have 2 identical header sections, with identical sequence numbers. This makes sure we detect VHDX images with identical headers, and do not flag them as corrupt. Signed-off-by: Jeff Cody <jcody@redhat.com> Reviewed-by: Fam Zheng <famz@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2014-05-13 18:00:53 +04:00
=== Verify image created by Disk2VHD can be opened ===
iotests: Use _img_info qemu-img info should only be used directly if the format-specific information or the name of the format is relevant (some tests explicitly test format-specific information; test 082 uses qcow2-specific settings to test the qemu-img interface); otherwise, tests should always use _img_info instead. Test 082 was touched only partially. It does test the qemu-img interface; however, its invocations of qemu-img info are not real tests but rather verifications, so if format-specific information is not important for the test, there is no reason not to use _img_info. In contrast to directly invoking qemu-img info, "qcow2" is replaced by "IMGFMT"; but as "qcow2" is only mentioned once in test 082 (in _supported_fmt), I consider this an improvement. Signed-off-by: Max Reitz <mreitz@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Message-id: 1412105489-7681-2-git-send-email-mreitz@redhat.com Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2014-09-30 23:31:27 +04:00
image: TEST_DIR/test-disk2vhd.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 20:11:01 +03:00
virtual size: 256 MiB (268435456 bytes)
block: add test for vhdx image created by Disk2VHD This adds a test for VHDX images created by Microsoft's tool, Disk2VHD. VHDX images created by this tool have 2 identical header sections, with identical sequence numbers. This makes sure we detect VHDX images with identical headers, and do not flag them as corrupt. Signed-off-by: Jeff Cody <jcody@redhat.com> Reviewed-by: Fam Zheng <famz@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2014-05-13 18:00:53 +04:00
cluster_size: 2097152
block: vhdx qemu-iotest - log replay of data sector This tests the replay of a data sector in a VHDX image file. The image file is a 10G dynamic image, with 4MB block size. The image was created with qemu-img, and the log left unplayed by modification of the vhdx image format driver. It was verified under both QEMU and Hyper-V that the image file, post log replay, matched. Signed-off-by: Jeff Cody <jcody@redhat.com> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2013-10-30 18:44:56 +04:00
*** done
Reference in New Issue Copy Permalink