is taken to match the geometry and only when the geometry is max'd
out, is the actual recorded size taken.
Note that qemu has the same logic for the fixed VHD format. However
that is known to conflict with Microsoft Azure, where the recorded
size of the image is what counts.
Pointed out by: gjb@
The image is not accepted for provisioning otherwise. Bump the
VHD creator tool version and the version of mkimg to signify our
success in provisioning.
Note that this also imapcts the dynamic VHD images.
Tested by: gjb@
of megabytes. This is on top of having the image rounded to the
matching geometry of the image size.
By rounding up to the next MB after rounding to the geometry, we
lost idempotency. Subsequent calls to resize the image will keep
increasing the image size.
Tested by: gjb@
multiple of the cylinder size. This is what qemu-img seems to
be doing. Make sure to handle boundary cases where increasing
the image size by 1 cyclinder's worth would also result in a
change of geometry.
a raw image with a VHD footer appended. There's little value that I
can see to use the fixed image type, but in order to make VHD images
for use by Microsoft's Azure platform, they must be fixed VHD images.
Support has been added by refactoring the code to re-use common code
and by adding a second output format structure. To created fixed VHD
images, specify "vhdf" as the output format.
Use this for VHD and VMDK to avoid allocating space in the image
for empty sectors.
Note that this negatively affects performance because mkimg uses a
temporary file for the intermediate storage. When mkimg has better
internal book keeping, performance can be significantly improved.
among others.
Add an undocumented option for unit testing (-y). When given, the image
will have UUIDs and timestamps synthesized in a way that gives identical
results across runs. As such, UUIDs stop being unique, globally or
otherwise.
VHD support requested by: gjb@
