2017-07-05 14:57:38 +02:00
|
|
|
QA output created by 178
|
|
|
|
|
== Input validation ==
|
|
|
|
|
|
|
|
|
|
Formatting 'TEST_DIR/t.IMGFMT', fmt=IMGFMT size=1073741824
|
|
|
|
|
qemu-img: Either --size N or one filename must be specified.
|
|
|
|
|
qemu-img: --size N cannot be used together with a filename.
|
|
|
|
|
qemu-img: At most one filename argument is allowed.
|
2020-02-21 12:25:21 +01:00
|
|
|
qemu-img: Either --size N or one filename must be specified.
|
|
|
|
|
qemu-img: --image-opts, -f, and -l require a filename argument.
|
|
|
|
|
qemu-img: --image-opts, -f, and -l require a filename argument.
|
|
|
|
|
qemu-img: --image-opts, -f, and -l require a filename argument.
|
2017-07-05 14:57:38 +02:00
|
|
|
qemu-img: Invalid option list: ,
|
|
|
|
|
qemu-img: Invalid parameter 'snapshot.foo'
|
2021-01-26 13:38:34 +01:00
|
|
|
qemu-img: Failed in parsing snapshot param 'snapshot.foo=bar'
|
2017-07-05 14:57:38 +02:00
|
|
|
qemu-img: --output must be used with human or json as argument.
|
utils: Improve qemu_strtosz() to have 64 bits of precision
We have multiple clients of qemu_strtosz (qemu-io, the opts visitor,
the keyval visitor), and it gets annoying that edge-case testing is
impacted by implicit rounding to 53 bits of precision due to parsing
with strtod(). As an example posted by Rich Jones:
$ nbdkit memory $(( 2**63 - 2**30 )) --run \
'build/qemu-io -f raw "$uri" -c "w -P 3 $(( 2**63 - 2**30 - 512 )) 512" '
write failed: Input/output error
because 9223372035781033472 got rounded to 0x7fffffffc0000000 which is
out of bounds.
It is also worth noting that our existing parser, by virtue of using
strtod(), accepts decimal AND hex numbers, even though test-cutils
previously lacked any coverage of the latter until the previous patch.
We do have existing clients that expect a hex parse to work (for
example, iotest 33 using qemu-io -c "write -P 0xa 0x200 0x400"), but
strtod() parses "08" as 8 rather than as an invalid octal number, so
we know there are no clients that depend on octal. Our use of
strtod() also means that "0x1.8k" would actually parse as 1536 (the
fraction is 8/16), rather than 1843 (if the fraction were 8/10); but
as this was not covered in the testsuite, I have no qualms forbidding
hex fractions as invalid, so this patch declares that the use of
fractions is only supported with decimal input, and enhances the
testsuite to document that.
Our previous use of strtod() meant that -1 parsed as a negative; now
that we parse with strtoull(), negative values can wrap around modulo
2^64, so we have to explicitly check whether the user passed in a '-';
and make it consistent to also reject '-0'. This has the minor effect
of treating negative values as EINVAL (with no change to endptr)
rather than ERANGE (with endptr advanced to what was parsed), visible
in the updated iotest output.
We also had no testsuite coverage of "1.1e0k", which happened to parse
under strtod() but is unlikely to occur in practice; as long as we are
making things more robust, it is easy enough to reject the use of
exponents in a strtod parse.
The fix is done by breaking the parse into an integer prefix (no loss
in precision), rejecting negative values (since we can no longer rely
on strtod() to do that), determining if a decimal or hexadecimal parse
was intended (with the new restriction that a fractional hex parse is
not allowed), and where appropriate, using a floating point fractional
parse (where we also scan to reject use of exponents in the fraction).
The bulk of the patch is then updates to the testsuite to match our
new precision, as well as adding new cases we reject (whether they
were rejected or inadvertently accepted before).
Signed-off-by: Eric Blake <eblake@redhat.com>
Message-Id: <20210211204438.1184395-3-eblake@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2021-02-11 21:44:36 +01:00
|
|
|
qemu-img: Invalid image size specified. You may use k, M, G, T, P or E suffixes for
|
|
|
|
|
qemu-img: kilobytes, megabytes, gigabytes, terabytes, petabytes and exabytes.
|
2017-07-05 14:57:38 +02:00
|
|
|
qemu-img: Unknown file format 'foo'
|
|
|
|
|
|
|
|
|
|
== Size calculation for a new file (human) ==
|
|
|
|
|
|
|
|
|
|
required size: 196608
|
|
|
|
|
fully allocated size: 196608
|
|
|
|
|
required size: 589824
|
|
|
|
|
fully allocated size: 2148073472
|
|
|
|
|
required size: 10747904
|
|
|
|
|
fully allocated size: 68730224640
|
|
|
|
|
required size: 42205184
|
|
|
|
|
fully allocated size: 274920112128
|
|
|
|
|
required size: 168034304
|
|
|
|
|
fully allocated size: 1099679662080
|
|
|
|
|
required size: 343650009088
|
|
|
|
|
fully allocated size: 2252143463694336
|
|
|
|
|
qemu-img: The image size is too large (try using a larger cluster size)
|
|
|
|
|
|
|
|
|
|
== Empty qcow2 input image (human) ==
|
|
|
|
|
|
|
|
|
|
Formatting 'TEST_DIR/t.IMGFMT', fmt=IMGFMT size=0
|
|
|
|
|
required size: 196608
|
|
|
|
|
fully allocated size: 196608
|
qcow2: Expose bitmaps' size during measure
It's useful to know how much space can be occupied by qcow2 persistent
bitmaps, even though such metadata is unrelated to the guest-visible
data. Report this value as an additional QMP field, present when
measuring an existing image and output format that both support
bitmaps. Update iotest 178 and 190 to updated output, as well as new
coverage in 190 demonstrating non-zero values made possible with the
recently-added qemu-img bitmap command (see 3b51ab4b).
The new 'bitmaps size:' field is displayed automatically as part of
'qemu-img measure' any time it is present in QMP (that is, any time
both the source image being measured and destination format support
bitmaps, even if the measurement is 0 because there are no bitmaps
present). If the field is absent, it means that no bitmaps can be
copied (source, destination, or both lack bitmaps, including when
measuring based on size rather than on a source image). This behavior
is compatible with an upcoming patch adding 'qemu-img convert
--bitmaps': that command will fail in the same situations where this
patch omits the field.
The addition of a new field demonstrates why we should always
zero-initialize qapi C structs; while the qcow2 driver still fully
populates all fields, the raw and crypto drivers had to be tweaked to
avoid uninitialized data.
Consideration was also given towards having a 'qemu-img measure
--bitmaps' which errors out when bitmaps are not possible, and
otherwise sums the bitmaps into the existing allocation totals rather
than displaying as a separate field, as a potential convenience
factor. But this was ultimately decided to be more complexity than
necessary when the QMP interface was sufficient enough with bitmaps
remaining a separate field.
See also: https://bugzilla.redhat.com/1779904
Reported-by: Nir Soffer <nsoffer@redhat.com>
Signed-off-by: Eric Blake <eblake@redhat.com>
Message-Id: <20200521192137.1120211-3-eblake@redhat.com>
Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
2020-05-21 21:21:34 +02:00
|
|
|
bitmaps size: 0
|
2017-07-05 14:57:38 +02:00
|
|
|
|
|
|
|
|
converted image file size in bytes: 196608
|
|
|
|
|
|
|
|
|
|
== qcow2 input image with data (human) ==
|
|
|
|
|
|
|
|
|
|
Formatting 'TEST_DIR/t.IMGFMT', fmt=IMGFMT size=1073741824
|
|
|
|
|
required size: 393216
|
|
|
|
|
fully allocated size: 1074135040
|
qcow2: Expose bitmaps' size during measure
It's useful to know how much space can be occupied by qcow2 persistent
bitmaps, even though such metadata is unrelated to the guest-visible
data. Report this value as an additional QMP field, present when
measuring an existing image and output format that both support
bitmaps. Update iotest 178 and 190 to updated output, as well as new
coverage in 190 demonstrating non-zero values made possible with the
recently-added qemu-img bitmap command (see 3b51ab4b).
The new 'bitmaps size:' field is displayed automatically as part of
'qemu-img measure' any time it is present in QMP (that is, any time
both the source image being measured and destination format support
bitmaps, even if the measurement is 0 because there are no bitmaps
present). If the field is absent, it means that no bitmaps can be
copied (source, destination, or both lack bitmaps, including when
measuring based on size rather than on a source image). This behavior
is compatible with an upcoming patch adding 'qemu-img convert
--bitmaps': that command will fail in the same situations where this
patch omits the field.
The addition of a new field demonstrates why we should always
zero-initialize qapi C structs; while the qcow2 driver still fully
populates all fields, the raw and crypto drivers had to be tweaked to
avoid uninitialized data.
Consideration was also given towards having a 'qemu-img measure
--bitmaps' which errors out when bitmaps are not possible, and
otherwise sums the bitmaps into the existing allocation totals rather
than displaying as a separate field, as a potential convenience
factor. But this was ultimately decided to be more complexity than
necessary when the QMP interface was sufficient enough with bitmaps
remaining a separate field.
See also: https://bugzilla.redhat.com/1779904
Reported-by: Nir Soffer <nsoffer@redhat.com>
Signed-off-by: Eric Blake <eblake@redhat.com>
Message-Id: <20200521192137.1120211-3-eblake@redhat.com>
Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
2020-05-21 21:21:34 +02:00
|
|
|
bitmaps size: 0
|
2017-07-05 14:57:38 +02:00
|
|
|
wrote 512/512 bytes at offset 512
|
|
|
|
|
512 bytes, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
|
|
|
|
|
wrote 65536/65536 bytes at offset 65536
|
|
|
|
|
64 KiB, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
|
|
|
|
|
wrote 64512/64512 bytes at offset 134217728
|
|
|
|
|
63 KiB, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
|
|
|
|
|
required size: 589824
|
|
|
|
|
fully allocated size: 1074135040
|
qcow2: Expose bitmaps' size during measure
It's useful to know how much space can be occupied by qcow2 persistent
bitmaps, even though such metadata is unrelated to the guest-visible
data. Report this value as an additional QMP field, present when
measuring an existing image and output format that both support
bitmaps. Update iotest 178 and 190 to updated output, as well as new
coverage in 190 demonstrating non-zero values made possible with the
recently-added qemu-img bitmap command (see 3b51ab4b).
The new 'bitmaps size:' field is displayed automatically as part of
'qemu-img measure' any time it is present in QMP (that is, any time
both the source image being measured and destination format support
bitmaps, even if the measurement is 0 because there are no bitmaps
present). If the field is absent, it means that no bitmaps can be
copied (source, destination, or both lack bitmaps, including when
measuring based on size rather than on a source image). This behavior
is compatible with an upcoming patch adding 'qemu-img convert
--bitmaps': that command will fail in the same situations where this
patch omits the field.
The addition of a new field demonstrates why we should always
zero-initialize qapi C structs; while the qcow2 driver still fully
populates all fields, the raw and crypto drivers had to be tweaked to
avoid uninitialized data.
Consideration was also given towards having a 'qemu-img measure
--bitmaps' which errors out when bitmaps are not possible, and
otherwise sums the bitmaps into the existing allocation totals rather
than displaying as a separate field, as a potential convenience
factor. But this was ultimately decided to be more complexity than
necessary when the QMP interface was sufficient enough with bitmaps
remaining a separate field.
See also: https://bugzilla.redhat.com/1779904
Reported-by: Nir Soffer <nsoffer@redhat.com>
Signed-off-by: Eric Blake <eblake@redhat.com>
Message-Id: <20200521192137.1120211-3-eblake@redhat.com>
Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
2020-05-21 21:21:34 +02:00
|
|
|
bitmaps size: 0
|
2017-07-05 14:57:38 +02:00
|
|
|
|
|
|
|
|
converted image file size in bytes: 524288
|
|
|
|
|
|
|
|
|
|
== qcow2 input image with internal snapshot (human) ==
|
|
|
|
|
|
|
|
|
|
required size: 524288
|
|
|
|
|
fully allocated size: 1074135040
|
qcow2: Expose bitmaps' size during measure
It's useful to know how much space can be occupied by qcow2 persistent
bitmaps, even though such metadata is unrelated to the guest-visible
data. Report this value as an additional QMP field, present when
measuring an existing image and output format that both support
bitmaps. Update iotest 178 and 190 to updated output, as well as new
coverage in 190 demonstrating non-zero values made possible with the
recently-added qemu-img bitmap command (see 3b51ab4b).
The new 'bitmaps size:' field is displayed automatically as part of
'qemu-img measure' any time it is present in QMP (that is, any time
both the source image being measured and destination format support
bitmaps, even if the measurement is 0 because there are no bitmaps
present). If the field is absent, it means that no bitmaps can be
copied (source, destination, or both lack bitmaps, including when
measuring based on size rather than on a source image). This behavior
is compatible with an upcoming patch adding 'qemu-img convert
--bitmaps': that command will fail in the same situations where this
patch omits the field.
The addition of a new field demonstrates why we should always
zero-initialize qapi C structs; while the qcow2 driver still fully
populates all fields, the raw and crypto drivers had to be tweaked to
avoid uninitialized data.
Consideration was also given towards having a 'qemu-img measure
--bitmaps' which errors out when bitmaps are not possible, and
otherwise sums the bitmaps into the existing allocation totals rather
than displaying as a separate field, as a potential convenience
factor. But this was ultimately decided to be more complexity than
necessary when the QMP interface was sufficient enough with bitmaps
remaining a separate field.
See also: https://bugzilla.redhat.com/1779904
Reported-by: Nir Soffer <nsoffer@redhat.com>
Signed-off-by: Eric Blake <eblake@redhat.com>
Message-Id: <20200521192137.1120211-3-eblake@redhat.com>
Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
2020-05-21 21:21:34 +02:00
|
|
|
bitmaps size: 0
|
2017-07-05 14:57:38 +02:00
|
|
|
|
|
|
|
|
converted image file size in bytes: 458752
|
|
|
|
|
|
|
|
|
|
== qcow2 input image and a backing file (human) ==
|
|
|
|
|
|
|
|
|
|
required size: 1074135040
|
|
|
|
|
fully allocated size: 1074135040
|
qcow2: Expose bitmaps' size during measure
It's useful to know how much space can be occupied by qcow2 persistent
bitmaps, even though such metadata is unrelated to the guest-visible
data. Report this value as an additional QMP field, present when
measuring an existing image and output format that both support
bitmaps. Update iotest 178 and 190 to updated output, as well as new
coverage in 190 demonstrating non-zero values made possible with the
recently-added qemu-img bitmap command (see 3b51ab4b).
The new 'bitmaps size:' field is displayed automatically as part of
'qemu-img measure' any time it is present in QMP (that is, any time
both the source image being measured and destination format support
bitmaps, even if the measurement is 0 because there are no bitmaps
present). If the field is absent, it means that no bitmaps can be
copied (source, destination, or both lack bitmaps, including when
measuring based on size rather than on a source image). This behavior
is compatible with an upcoming patch adding 'qemu-img convert
--bitmaps': that command will fail in the same situations where this
patch omits the field.
The addition of a new field demonstrates why we should always
zero-initialize qapi C structs; while the qcow2 driver still fully
populates all fields, the raw and crypto drivers had to be tweaked to
avoid uninitialized data.
Consideration was also given towards having a 'qemu-img measure
--bitmaps' which errors out when bitmaps are not possible, and
otherwise sums the bitmaps into the existing allocation totals rather
than displaying as a separate field, as a potential convenience
factor. But this was ultimately decided to be more complexity than
necessary when the QMP interface was sufficient enough with bitmaps
remaining a separate field.
See also: https://bugzilla.redhat.com/1779904
Reported-by: Nir Soffer <nsoffer@redhat.com>
Signed-off-by: Eric Blake <eblake@redhat.com>
Message-Id: <20200521192137.1120211-3-eblake@redhat.com>
Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
2020-05-21 21:21:34 +02:00
|
|
|
bitmaps size: 0
|
2017-07-05 14:57:38 +02:00
|
|
|
|
2019-02-18 11:45:25 +01:00
|
|
|
== qcow2 input image and LUKS encryption ==
|
|
|
|
|
|
|
|
|
|
required size: 2686976
|
|
|
|
|
fully allocated size: 1076232192
|
qcow2: Expose bitmaps' size during measure
It's useful to know how much space can be occupied by qcow2 persistent
bitmaps, even though such metadata is unrelated to the guest-visible
data. Report this value as an additional QMP field, present when
measuring an existing image and output format that both support
bitmaps. Update iotest 178 and 190 to updated output, as well as new
coverage in 190 demonstrating non-zero values made possible with the
recently-added qemu-img bitmap command (see 3b51ab4b).
The new 'bitmaps size:' field is displayed automatically as part of
'qemu-img measure' any time it is present in QMP (that is, any time
both the source image being measured and destination format support
bitmaps, even if the measurement is 0 because there are no bitmaps
present). If the field is absent, it means that no bitmaps can be
copied (source, destination, or both lack bitmaps, including when
measuring based on size rather than on a source image). This behavior
is compatible with an upcoming patch adding 'qemu-img convert
--bitmaps': that command will fail in the same situations where this
patch omits the field.
The addition of a new field demonstrates why we should always
zero-initialize qapi C structs; while the qcow2 driver still fully
populates all fields, the raw and crypto drivers had to be tweaked to
avoid uninitialized data.
Consideration was also given towards having a 'qemu-img measure
--bitmaps' which errors out when bitmaps are not possible, and
otherwise sums the bitmaps into the existing allocation totals rather
than displaying as a separate field, as a potential convenience
factor. But this was ultimately decided to be more complexity than
necessary when the QMP interface was sufficient enough with bitmaps
remaining a separate field.
See also: https://bugzilla.redhat.com/1779904
Reported-by: Nir Soffer <nsoffer@redhat.com>
Signed-off-by: Eric Blake <eblake@redhat.com>
Message-Id: <20200521192137.1120211-3-eblake@redhat.com>
Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
2020-05-21 21:21:34 +02:00
|
|
|
bitmaps size: 0
|
2019-02-18 11:45:25 +01:00
|
|
|
|
2017-07-05 14:57:38 +02:00
|
|
|
== qcow2 input image and preallocation (human) ==
|
|
|
|
|
|
|
|
|
|
required size: 1074135040
|
|
|
|
|
fully allocated size: 1074135040
|
qcow2: Expose bitmaps' size during measure
It's useful to know how much space can be occupied by qcow2 persistent
bitmaps, even though such metadata is unrelated to the guest-visible
data. Report this value as an additional QMP field, present when
measuring an existing image and output format that both support
bitmaps. Update iotest 178 and 190 to updated output, as well as new
coverage in 190 demonstrating non-zero values made possible with the
recently-added qemu-img bitmap command (see 3b51ab4b).
The new 'bitmaps size:' field is displayed automatically as part of
'qemu-img measure' any time it is present in QMP (that is, any time
both the source image being measured and destination format support
bitmaps, even if the measurement is 0 because there are no bitmaps
present). If the field is absent, it means that no bitmaps can be
copied (source, destination, or both lack bitmaps, including when
measuring based on size rather than on a source image). This behavior
is compatible with an upcoming patch adding 'qemu-img convert
--bitmaps': that command will fail in the same situations where this
patch omits the field.
The addition of a new field demonstrates why we should always
zero-initialize qapi C structs; while the qcow2 driver still fully
populates all fields, the raw and crypto drivers had to be tweaked to
avoid uninitialized data.
Consideration was also given towards having a 'qemu-img measure
--bitmaps' which errors out when bitmaps are not possible, and
otherwise sums the bitmaps into the existing allocation totals rather
than displaying as a separate field, as a potential convenience
factor. But this was ultimately decided to be more complexity than
necessary when the QMP interface was sufficient enough with bitmaps
remaining a separate field.
See also: https://bugzilla.redhat.com/1779904
Reported-by: Nir Soffer <nsoffer@redhat.com>
Signed-off-by: Eric Blake <eblake@redhat.com>
Message-Id: <20200521192137.1120211-3-eblake@redhat.com>
Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
2020-05-21 21:21:34 +02:00
|
|
|
bitmaps size: 0
|
2017-07-05 14:57:38 +02:00
|
|
|
|
|
|
|
|
converted image file size in bytes: 1074135040
|
|
|
|
|
|
|
|
|
|
== Fully-allocated qcow2 input image (human) ==
|
|
|
|
|
|
|
|
|
|
Formatting 'TEST_DIR/t.IMGFMT', fmt=IMGFMT size=8388608
|
|
|
|
|
wrote 8388608/8388608 bytes at offset 0
|
|
|
|
|
8 MiB, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
|
|
|
|
|
required size: 8716288
|
|
|
|
|
fully allocated size: 8716288
|
qcow2: Expose bitmaps' size during measure
It's useful to know how much space can be occupied by qcow2 persistent
bitmaps, even though such metadata is unrelated to the guest-visible
data. Report this value as an additional QMP field, present when
measuring an existing image and output format that both support
bitmaps. Update iotest 178 and 190 to updated output, as well as new
coverage in 190 demonstrating non-zero values made possible with the
recently-added qemu-img bitmap command (see 3b51ab4b).
The new 'bitmaps size:' field is displayed automatically as part of
'qemu-img measure' any time it is present in QMP (that is, any time
both the source image being measured and destination format support
bitmaps, even if the measurement is 0 because there are no bitmaps
present). If the field is absent, it means that no bitmaps can be
copied (source, destination, or both lack bitmaps, including when
measuring based on size rather than on a source image). This behavior
is compatible with an upcoming patch adding 'qemu-img convert
--bitmaps': that command will fail in the same situations where this
patch omits the field.
The addition of a new field demonstrates why we should always
zero-initialize qapi C structs; while the qcow2 driver still fully
populates all fields, the raw and crypto drivers had to be tweaked to
avoid uninitialized data.
Consideration was also given towards having a 'qemu-img measure
--bitmaps' which errors out when bitmaps are not possible, and
otherwise sums the bitmaps into the existing allocation totals rather
than displaying as a separate field, as a potential convenience
factor. But this was ultimately decided to be more complexity than
necessary when the QMP interface was sufficient enough with bitmaps
remaining a separate field.
See also: https://bugzilla.redhat.com/1779904
Reported-by: Nir Soffer <nsoffer@redhat.com>
Signed-off-by: Eric Blake <eblake@redhat.com>
Message-Id: <20200521192137.1120211-3-eblake@redhat.com>
Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
2020-05-21 21:21:34 +02:00
|
|
|
bitmaps size: 0
|
2017-07-05 14:57:38 +02:00
|
|
|
|
|
|
|
|
converted image file size in bytes: 8716288
|
|
|
|
|
|
|
|
|
|
== Empty raw input image (human) ==
|
|
|
|
|
|
|
|
|
|
Formatting 'TEST_DIR/t.qcow2', fmt=IMGFMT size=0
|
|
|
|
|
required size: 196608
|
|
|
|
|
fully allocated size: 196608
|
|
|
|
|
|
|
|
|
|
converted image file size in bytes: 196608
|
|
|
|
|
|
|
|
|
|
== raw input image with data (human) ==
|
|
|
|
|
|
|
|
|
|
Formatting 'TEST_DIR/t.qcow2', fmt=IMGFMT size=1073741824
|
2019-08-27 03:05:27 +02:00
|
|
|
required size: 458752
|
2017-07-05 14:57:38 +02:00
|
|
|
fully allocated size: 1074135040
|
|
|
|
|
wrote 512/512 bytes at offset 512
|
|
|
|
|
512 bytes, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
|
|
|
|
|
wrote 65536/65536 bytes at offset 65536
|
|
|
|
|
64 KiB, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
|
|
|
|
|
wrote 64512/64512 bytes at offset 134217728
|
|
|
|
|
63 KiB, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
|
|
|
|
|
required size: 589824
|
|
|
|
|
fully allocated size: 1074135040
|
|
|
|
|
|
|
|
|
|
converted image file size in bytes: 524288
|
|
|
|
|
|
|
|
|
|
== raw input image and a backing file (human) ==
|
|
|
|
|
|
|
|
|
|
required size: 1074135040
|
|
|
|
|
fully allocated size: 1074135040
|
|
|
|
|
|
2019-02-18 11:45:25 +01:00
|
|
|
== raw input image and LUKS encryption ==
|
|
|
|
|
|
|
|
|
|
required size: 2686976
|
|
|
|
|
fully allocated size: 1076232192
|
|
|
|
|
|
2017-07-05 14:57:38 +02:00
|
|
|
== raw input image and preallocation (human) ==
|
|
|
|
|
|
|
|
|
|
required size: 1074135040
|
|
|
|
|
fully allocated size: 1074135040
|
|
|
|
|
|
|
|
|
|
converted image file size in bytes: 1074135040
|
|
|
|
|
|
|
|
|
|
== Fully-allocated raw input image (human) ==
|
|
|
|
|
|
|
|
|
|
Formatting 'TEST_DIR/t.qcow2', fmt=IMGFMT size=8388608
|
|
|
|
|
wrote 8388608/8388608 bytes at offset 0
|
|
|
|
|
8 MiB, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
|
|
|
|
|
required size: 8716288
|
|
|
|
|
fully allocated size: 8716288
|
|
|
|
|
|
|
|
|
|
converted image file size in bytes: 8716288
|
|
|
|
|
|
|
|
|
|
== Size calculation for a new file (json) ==
|
|
|
|
|
|
|
|
|
|
{
|
|
|
|
|
"required": 196608,
|
|
|
|
|
"fully-allocated": 196608
|
|
|
|
|
}
|
|
|
|
|
{
|
|
|
|
|
"required": 589824,
|
|
|
|
|
"fully-allocated": 2148073472
|
|
|
|
|
}
|
|
|
|
|
{
|
|
|
|
|
"required": 10747904,
|
|
|
|
|
"fully-allocated": 68730224640
|
|
|
|
|
}
|
|
|
|
|
{
|
|
|
|
|
"required": 42205184,
|
|
|
|
|
"fully-allocated": 274920112128
|
|
|
|
|
}
|
|
|
|
|
{
|
|
|
|
|
"required": 168034304,
|
|
|
|
|
"fully-allocated": 1099679662080
|
|
|
|
|
}
|
|
|
|
|
{
|
|
|
|
|
"required": 343650009088,
|
|
|
|
|
"fully-allocated": 2252143463694336
|
|
|
|
|
}
|
|
|
|
|
qemu-img: The image size is too large (try using a larger cluster size)
|
|
|
|
|
|
|
|
|
|
== Empty qcow2 input image (json) ==
|
|
|
|
|
|
|
|
|
|
Formatting 'TEST_DIR/t.IMGFMT', fmt=IMGFMT size=0
|
|
|
|
|
{
|
qcow2: Expose bitmaps' size during measure
It's useful to know how much space can be occupied by qcow2 persistent
bitmaps, even though such metadata is unrelated to the guest-visible
data. Report this value as an additional QMP field, present when
measuring an existing image and output format that both support
bitmaps. Update iotest 178 and 190 to updated output, as well as new
coverage in 190 demonstrating non-zero values made possible with the
recently-added qemu-img bitmap command (see 3b51ab4b).
The new 'bitmaps size:' field is displayed automatically as part of
'qemu-img measure' any time it is present in QMP (that is, any time
both the source image being measured and destination format support
bitmaps, even if the measurement is 0 because there are no bitmaps
present). If the field is absent, it means that no bitmaps can be
copied (source, destination, or both lack bitmaps, including when
measuring based on size rather than on a source image). This behavior
is compatible with an upcoming patch adding 'qemu-img convert
--bitmaps': that command will fail in the same situations where this
patch omits the field.
The addition of a new field demonstrates why we should always
zero-initialize qapi C structs; while the qcow2 driver still fully
populates all fields, the raw and crypto drivers had to be tweaked to
avoid uninitialized data.
Consideration was also given towards having a 'qemu-img measure
--bitmaps' which errors out when bitmaps are not possible, and
otherwise sums the bitmaps into the existing allocation totals rather
than displaying as a separate field, as a potential convenience
factor. But this was ultimately decided to be more complexity than
necessary when the QMP interface was sufficient enough with bitmaps
remaining a separate field.
See also: https://bugzilla.redhat.com/1779904
Reported-by: Nir Soffer <nsoffer@redhat.com>
Signed-off-by: Eric Blake <eblake@redhat.com>
Message-Id: <20200521192137.1120211-3-eblake@redhat.com>
Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
2020-05-21 21:21:34 +02:00
|
|
|
"bitmaps": 0,
|
2017-07-05 14:57:38 +02:00
|
|
|
"required": 196608,
|
|
|
|
|
"fully-allocated": 196608
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
converted image file size in bytes: 196608
|
|
|
|
|
|
|
|
|
|
== qcow2 input image with data (json) ==
|
|
|
|
|
|
|
|
|
|
Formatting 'TEST_DIR/t.IMGFMT', fmt=IMGFMT size=1073741824
|
|
|
|
|
{
|
qcow2: Expose bitmaps' size during measure
It's useful to know how much space can be occupied by qcow2 persistent
bitmaps, even though such metadata is unrelated to the guest-visible
data. Report this value as an additional QMP field, present when
measuring an existing image and output format that both support
bitmaps. Update iotest 178 and 190 to updated output, as well as new
coverage in 190 demonstrating non-zero values made possible with the
recently-added qemu-img bitmap command (see 3b51ab4b).
The new 'bitmaps size:' field is displayed automatically as part of
'qemu-img measure' any time it is present in QMP (that is, any time
both the source image being measured and destination format support
bitmaps, even if the measurement is 0 because there are no bitmaps
present). If the field is absent, it means that no bitmaps can be
copied (source, destination, or both lack bitmaps, including when
measuring based on size rather than on a source image). This behavior
is compatible with an upcoming patch adding 'qemu-img convert
--bitmaps': that command will fail in the same situations where this
patch omits the field.
The addition of a new field demonstrates why we should always
zero-initialize qapi C structs; while the qcow2 driver still fully
populates all fields, the raw and crypto drivers had to be tweaked to
avoid uninitialized data.
Consideration was also given towards having a 'qemu-img measure
--bitmaps' which errors out when bitmaps are not possible, and
otherwise sums the bitmaps into the existing allocation totals rather
than displaying as a separate field, as a potential convenience
factor. But this was ultimately decided to be more complexity than
necessary when the QMP interface was sufficient enough with bitmaps
remaining a separate field.
See also: https://bugzilla.redhat.com/1779904
Reported-by: Nir Soffer <nsoffer@redhat.com>
Signed-off-by: Eric Blake <eblake@redhat.com>
Message-Id: <20200521192137.1120211-3-eblake@redhat.com>
Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
2020-05-21 21:21:34 +02:00
|
|
|
"bitmaps": 0,
|
2017-07-05 14:57:38 +02:00
|
|
|
"required": 393216,
|
|
|
|
|
"fully-allocated": 1074135040
|
|
|
|
|
}
|
|
|
|
|
wrote 512/512 bytes at offset 512
|
|
|
|
|
512 bytes, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
|
|
|
|
|
wrote 65536/65536 bytes at offset 65536
|
|
|
|
|
64 KiB, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
|
|
|
|
|
wrote 64512/64512 bytes at offset 134217728
|
|
|
|
|
63 KiB, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
|
|
|
|
|
{
|
qcow2: Expose bitmaps' size during measure
It's useful to know how much space can be occupied by qcow2 persistent
bitmaps, even though such metadata is unrelated to the guest-visible
data. Report this value as an additional QMP field, present when
measuring an existing image and output format that both support
bitmaps. Update iotest 178 and 190 to updated output, as well as new
coverage in 190 demonstrating non-zero values made possible with the
recently-added qemu-img bitmap command (see 3b51ab4b).
The new 'bitmaps size:' field is displayed automatically as part of
'qemu-img measure' any time it is present in QMP (that is, any time
both the source image being measured and destination format support
bitmaps, even if the measurement is 0 because there are no bitmaps
present). If the field is absent, it means that no bitmaps can be
copied (source, destination, or both lack bitmaps, including when
measuring based on size rather than on a source image). This behavior
is compatible with an upcoming patch adding 'qemu-img convert
--bitmaps': that command will fail in the same situations where this
patch omits the field.
The addition of a new field demonstrates why we should always
zero-initialize qapi C structs; while the qcow2 driver still fully
populates all fields, the raw and crypto drivers had to be tweaked to
avoid uninitialized data.
Consideration was also given towards having a 'qemu-img measure
--bitmaps' which errors out when bitmaps are not possible, and
otherwise sums the bitmaps into the existing allocation totals rather
than displaying as a separate field, as a potential convenience
factor. But this was ultimately decided to be more complexity than
necessary when the QMP interface was sufficient enough with bitmaps
remaining a separate field.
See also: https://bugzilla.redhat.com/1779904
Reported-by: Nir Soffer <nsoffer@redhat.com>
Signed-off-by: Eric Blake <eblake@redhat.com>
Message-Id: <20200521192137.1120211-3-eblake@redhat.com>
Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
2020-05-21 21:21:34 +02:00
|
|
|
"bitmaps": 0,
|
2017-07-05 14:57:38 +02:00
|
|
|
"required": 589824,
|
|
|
|
|
"fully-allocated": 1074135040
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
converted image file size in bytes: 524288
|
|
|
|
|
|
|
|
|
|
== qcow2 input image with internal snapshot (json) ==
|
|
|
|
|
|
|
|
|
|
{
|
qcow2: Expose bitmaps' size during measure
It's useful to know how much space can be occupied by qcow2 persistent
bitmaps, even though such metadata is unrelated to the guest-visible
data. Report this value as an additional QMP field, present when
measuring an existing image and output format that both support
bitmaps. Update iotest 178 and 190 to updated output, as well as new
coverage in 190 demonstrating non-zero values made possible with the
recently-added qemu-img bitmap command (see 3b51ab4b).
The new 'bitmaps size:' field is displayed automatically as part of
'qemu-img measure' any time it is present in QMP (that is, any time
both the source image being measured and destination format support
bitmaps, even if the measurement is 0 because there are no bitmaps
present). If the field is absent, it means that no bitmaps can be
copied (source, destination, or both lack bitmaps, including when
measuring based on size rather than on a source image). This behavior
is compatible with an upcoming patch adding 'qemu-img convert
--bitmaps': that command will fail in the same situations where this
patch omits the field.
The addition of a new field demonstrates why we should always
zero-initialize qapi C structs; while the qcow2 driver still fully
populates all fields, the raw and crypto drivers had to be tweaked to
avoid uninitialized data.
Consideration was also given towards having a 'qemu-img measure
--bitmaps' which errors out when bitmaps are not possible, and
otherwise sums the bitmaps into the existing allocation totals rather
than displaying as a separate field, as a potential convenience
factor. But this was ultimately decided to be more complexity than
necessary when the QMP interface was sufficient enough with bitmaps
remaining a separate field.
See also: https://bugzilla.redhat.com/1779904
Reported-by: Nir Soffer <nsoffer@redhat.com>
Signed-off-by: Eric Blake <eblake@redhat.com>
Message-Id: <20200521192137.1120211-3-eblake@redhat.com>
Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
2020-05-21 21:21:34 +02:00
|
|
|
"bitmaps": 0,
|
2017-07-05 14:57:38 +02:00
|
|
|
"required": 524288,
|
|
|
|
|
"fully-allocated": 1074135040
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
converted image file size in bytes: 458752
|
|
|
|
|
|
|
|
|
|
== qcow2 input image and a backing file (json) ==
|
|
|
|
|
|
|
|
|
|
{
|
qcow2: Expose bitmaps' size during measure
It's useful to know how much space can be occupied by qcow2 persistent
bitmaps, even though such metadata is unrelated to the guest-visible
data. Report this value as an additional QMP field, present when
measuring an existing image and output format that both support
bitmaps. Update iotest 178 and 190 to updated output, as well as new
coverage in 190 demonstrating non-zero values made possible with the
recently-added qemu-img bitmap command (see 3b51ab4b).
The new 'bitmaps size:' field is displayed automatically as part of
'qemu-img measure' any time it is present in QMP (that is, any time
both the source image being measured and destination format support
bitmaps, even if the measurement is 0 because there are no bitmaps
present). If the field is absent, it means that no bitmaps can be
copied (source, destination, or both lack bitmaps, including when
measuring based on size rather than on a source image). This behavior
is compatible with an upcoming patch adding 'qemu-img convert
--bitmaps': that command will fail in the same situations where this
patch omits the field.
The addition of a new field demonstrates why we should always
zero-initialize qapi C structs; while the qcow2 driver still fully
populates all fields, the raw and crypto drivers had to be tweaked to
avoid uninitialized data.
Consideration was also given towards having a 'qemu-img measure
--bitmaps' which errors out when bitmaps are not possible, and
otherwise sums the bitmaps into the existing allocation totals rather
than displaying as a separate field, as a potential convenience
factor. But this was ultimately decided to be more complexity than
necessary when the QMP interface was sufficient enough with bitmaps
remaining a separate field.
See also: https://bugzilla.redhat.com/1779904
Reported-by: Nir Soffer <nsoffer@redhat.com>
Signed-off-by: Eric Blake <eblake@redhat.com>
Message-Id: <20200521192137.1120211-3-eblake@redhat.com>
Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
2020-05-21 21:21:34 +02:00
|
|
|
"bitmaps": 0,
|
2017-07-05 14:57:38 +02:00
|
|
|
"required": 1074135040,
|
|
|
|
|
"fully-allocated": 1074135040
|
|
|
|
|
}
|
|
|
|
|
|
2019-02-18 11:45:25 +01:00
|
|
|
== qcow2 input image and LUKS encryption ==
|
|
|
|
|
|
|
|
|
|
{
|
qcow2: Expose bitmaps' size during measure
It's useful to know how much space can be occupied by qcow2 persistent
bitmaps, even though such metadata is unrelated to the guest-visible
data. Report this value as an additional QMP field, present when
measuring an existing image and output format that both support
bitmaps. Update iotest 178 and 190 to updated output, as well as new
coverage in 190 demonstrating non-zero values made possible with the
recently-added qemu-img bitmap command (see 3b51ab4b).
The new 'bitmaps size:' field is displayed automatically as part of
'qemu-img measure' any time it is present in QMP (that is, any time
both the source image being measured and destination format support
bitmaps, even if the measurement is 0 because there are no bitmaps
present). If the field is absent, it means that no bitmaps can be
copied (source, destination, or both lack bitmaps, including when
measuring based on size rather than on a source image). This behavior
is compatible with an upcoming patch adding 'qemu-img convert
--bitmaps': that command will fail in the same situations where this
patch omits the field.
The addition of a new field demonstrates why we should always
zero-initialize qapi C structs; while the qcow2 driver still fully
populates all fields, the raw and crypto drivers had to be tweaked to
avoid uninitialized data.
Consideration was also given towards having a 'qemu-img measure
--bitmaps' which errors out when bitmaps are not possible, and
otherwise sums the bitmaps into the existing allocation totals rather
than displaying as a separate field, as a potential convenience
factor. But this was ultimately decided to be more complexity than
necessary when the QMP interface was sufficient enough with bitmaps
remaining a separate field.
See also: https://bugzilla.redhat.com/1779904
Reported-by: Nir Soffer <nsoffer@redhat.com>
Signed-off-by: Eric Blake <eblake@redhat.com>
Message-Id: <20200521192137.1120211-3-eblake@redhat.com>
Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
2020-05-21 21:21:34 +02:00
|
|
|
"bitmaps": 0,
|
2019-02-18 11:45:25 +01:00
|
|
|
"required": 2686976,
|
|
|
|
|
"fully-allocated": 1076232192
|
|
|
|
|
}
|
|
|
|
|
|
2017-07-05 14:57:38 +02:00
|
|
|
== qcow2 input image and preallocation (json) ==
|
|
|
|
|
|
|
|
|
|
{
|
qcow2: Expose bitmaps' size during measure
It's useful to know how much space can be occupied by qcow2 persistent
bitmaps, even though such metadata is unrelated to the guest-visible
data. Report this value as an additional QMP field, present when
measuring an existing image and output format that both support
bitmaps. Update iotest 178 and 190 to updated output, as well as new
coverage in 190 demonstrating non-zero values made possible with the
recently-added qemu-img bitmap command (see 3b51ab4b).
The new 'bitmaps size:' field is displayed automatically as part of
'qemu-img measure' any time it is present in QMP (that is, any time
both the source image being measured and destination format support
bitmaps, even if the measurement is 0 because there are no bitmaps
present). If the field is absent, it means that no bitmaps can be
copied (source, destination, or both lack bitmaps, including when
measuring based on size rather than on a source image). This behavior
is compatible with an upcoming patch adding 'qemu-img convert
--bitmaps': that command will fail in the same situations where this
patch omits the field.
The addition of a new field demonstrates why we should always
zero-initialize qapi C structs; while the qcow2 driver still fully
populates all fields, the raw and crypto drivers had to be tweaked to
avoid uninitialized data.
Consideration was also given towards having a 'qemu-img measure
--bitmaps' which errors out when bitmaps are not possible, and
otherwise sums the bitmaps into the existing allocation totals rather
than displaying as a separate field, as a potential convenience
factor. But this was ultimately decided to be more complexity than
necessary when the QMP interface was sufficient enough with bitmaps
remaining a separate field.
See also: https://bugzilla.redhat.com/1779904
Reported-by: Nir Soffer <nsoffer@redhat.com>
Signed-off-by: Eric Blake <eblake@redhat.com>
Message-Id: <20200521192137.1120211-3-eblake@redhat.com>
Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
2020-05-21 21:21:34 +02:00
|
|
|
"bitmaps": 0,
|
2017-07-05 14:57:38 +02:00
|
|
|
"required": 1074135040,
|
|
|
|
|
"fully-allocated": 1074135040
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
converted image file size in bytes: 1074135040
|
|
|
|
|
|
|
|
|
|
== Fully-allocated qcow2 input image (json) ==
|
|
|
|
|
|
|
|
|
|
Formatting 'TEST_DIR/t.IMGFMT', fmt=IMGFMT size=8388608
|
|
|
|
|
wrote 8388608/8388608 bytes at offset 0
|
|
|
|
|
8 MiB, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
|
|
|
|
|
{
|
qcow2: Expose bitmaps' size during measure
It's useful to know how much space can be occupied by qcow2 persistent
bitmaps, even though such metadata is unrelated to the guest-visible
data. Report this value as an additional QMP field, present when
measuring an existing image and output format that both support
bitmaps. Update iotest 178 and 190 to updated output, as well as new
coverage in 190 demonstrating non-zero values made possible with the
recently-added qemu-img bitmap command (see 3b51ab4b).
The new 'bitmaps size:' field is displayed automatically as part of
'qemu-img measure' any time it is present in QMP (that is, any time
both the source image being measured and destination format support
bitmaps, even if the measurement is 0 because there are no bitmaps
present). If the field is absent, it means that no bitmaps can be
copied (source, destination, or both lack bitmaps, including when
measuring based on size rather than on a source image). This behavior
is compatible with an upcoming patch adding 'qemu-img convert
--bitmaps': that command will fail in the same situations where this
patch omits the field.
The addition of a new field demonstrates why we should always
zero-initialize qapi C structs; while the qcow2 driver still fully
populates all fields, the raw and crypto drivers had to be tweaked to
avoid uninitialized data.
Consideration was also given towards having a 'qemu-img measure
--bitmaps' which errors out when bitmaps are not possible, and
otherwise sums the bitmaps into the existing allocation totals rather
than displaying as a separate field, as a potential convenience
factor. But this was ultimately decided to be more complexity than
necessary when the QMP interface was sufficient enough with bitmaps
remaining a separate field.
See also: https://bugzilla.redhat.com/1779904
Reported-by: Nir Soffer <nsoffer@redhat.com>
Signed-off-by: Eric Blake <eblake@redhat.com>
Message-Id: <20200521192137.1120211-3-eblake@redhat.com>
Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
2020-05-21 21:21:34 +02:00
|
|
|
"bitmaps": 0,
|
2017-07-05 14:57:38 +02:00
|
|
|
"required": 8716288,
|
|
|
|
|
"fully-allocated": 8716288
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
converted image file size in bytes: 8716288
|
|
|
|
|
|
|
|
|
|
== Empty raw input image (json) ==
|
|
|
|
|
|
|
|
|
|
Formatting 'TEST_DIR/t.qcow2', fmt=IMGFMT size=0
|
|
|
|
|
{
|
|
|
|
|
"required": 196608,
|
|
|
|
|
"fully-allocated": 196608
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
converted image file size in bytes: 196608
|
|
|
|
|
|
|
|
|
|
== raw input image with data (json) ==
|
|
|
|
|
|
|
|
|
|
Formatting 'TEST_DIR/t.qcow2', fmt=IMGFMT size=1073741824
|
|
|
|
|
{
|
2019-08-27 03:05:27 +02:00
|
|
|
"required": 458752,
|
2017-07-05 14:57:38 +02:00
|
|
|
"fully-allocated": 1074135040
|
|
|
|
|
}
|
|
|
|
|
wrote 512/512 bytes at offset 512
|
|
|
|
|
512 bytes, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
|
|
|
|
|
wrote 65536/65536 bytes at offset 65536
|
|
|
|
|
64 KiB, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
|
|
|
|
|
wrote 64512/64512 bytes at offset 134217728
|
|
|
|
|
63 KiB, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
|
|
|
|
|
{
|
|
|
|
|
"required": 589824,
|
|
|
|
|
"fully-allocated": 1074135040
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
converted image file size in bytes: 524288
|
|
|
|
|
|
|
|
|
|
== raw input image and a backing file (json) ==
|
|
|
|
|
|
|
|
|
|
{
|
|
|
|
|
"required": 1074135040,
|
|
|
|
|
"fully-allocated": 1074135040
|
|
|
|
|
}
|
|
|
|
|
|
2019-02-18 11:45:25 +01:00
|
|
|
== raw input image and LUKS encryption ==
|
|
|
|
|
|
|
|
|
|
{
|
|
|
|
|
"required": 2686976,
|
|
|
|
|
"fully-allocated": 1076232192
|
|
|
|
|
}
|
|
|
|
|
|
2017-07-05 14:57:38 +02:00
|
|
|
== raw input image and preallocation (json) ==
|
|
|
|
|
|
|
|
|
|
{
|
|
|
|
|
"required": 1074135040,
|
|
|
|
|
"fully-allocated": 1074135040
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
converted image file size in bytes: 1074135040
|
|
|
|
|
|
|
|
|
|
== Fully-allocated raw input image (json) ==
|
|
|
|
|
|
|
|
|
|
Formatting 'TEST_DIR/t.qcow2', fmt=IMGFMT size=8388608
|
|
|
|
|
wrote 8388608/8388608 bytes at offset 0
|
|
|
|
|
8 MiB, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
|
|
|
|
|
{
|
|
|
|
|
"required": 8716288,
|
|
|
|
|
"fully-allocated": 8716288
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
converted image file size in bytes: 8716288
|
|
|
|
|
*** done
|
