It's possible that we diverge from the specification with our
implementation. Having a reference image in the test cases may detect
such problems when we introduce a bug that can read what it creates, but
can't handle a real VMDK.
Signed-off-by: Fam Zheng <famz@redhat.com>
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
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>
The first test case would cause a huge memory allocation, leading to a
qemu abort; the second one to a too small malloc() for the catalog
(smaller than s->catalog_size), which causes a read-only out-of-bounds
array access and on big endian hosts an endianess conversion for an
undefined memory area.
The sample image used here is not an original Parallels image. It was
created using an hexeditor on the basis of the struct that qemu uses.
Good enough for trying to crash the driver, but not for ensuring
compatibility.
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Reviewed-by: Max Reitz <mreitz@redhat.com>
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
Reviewed-by: Max Reitz <mreitz@redhat.com>
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Add a cloop format-specific test case. Later patches add tests for
input validation to the script.
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Reviewed-by: Max Reitz <mreitz@redhat.com>
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
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>
This adds the VHDX format to the qemu-iotests format, and adds
a read test. The test reads from an existing sample image, that
was created with Hyper-V under Windwos Server 2012.
The image file is a 1GB dynamic image, with 32MB blocks.
The pattern 0xa5 exists from 0MB-33MB (past a block size boundary)
The pattern 0x96 exists from 33MB-66MB (past another block boundary,
and leaving a partial blank block)
From 66MB-1024MB, all reads should return 0.
Although 1GB dynamic image with 66MB of data, the bzip2'ed image
file size is only 874 bytes.
This also adds in the IMGFMT_GENERIC flag, so r/o images can be
tested (e.g. ./check -vhdx) without failing tests that assume
r/w support.
Signed-off-by: Jeff Cody <jcody@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
For image formats that are not "QEMU native", but supported for
compatibility, it is useful to verify that an image created with
the 'gold standard' native tool can be read / written to successfully
by QEMU.
In addition to testing non-native images, this could also be useful to
test against image files created by older versions of QEMU.
This provides a directory to store small sample images, for use by
scripts in tests/qemu-iotests.
Image files should be compressed with bzip2.
To use a sample image from a bash script, the _use_sample_img function
will copy and decompress the image into $TEST_DIR, and set $TEST_IMG to
be the decompressed sample image copy. To cleanup, call
_cleanup_test_img as normal.
Signed-off-by: Jeff Cody <jcody@redhat.com>
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
