The most important reason for this is to reduce the size of the image being transferred. When converting to
.gvmi all redundant layers from the Docker image are discarded and the filesystem itself gets compressed using
This results in a substantial size difference between the two images. For example, as of the time of writing this answer, the Docker image built as part of Creating a Docker image article is about
650 MB in disk size. After conversion, the resulting
.gvmi file weighs around
50 MB. That's a 13x size difference!
But why do we need this? Most importantly, to reduce the setup time for providers downloading a new image. If a provider node does not have the specific image in their cache yet then it will need to download it as the first step to performing some computations.
There is only one strict requirement: at least one volume directory must be specified using the
Besides the above a number of commands are currently not supported by
gvmkit-build converter. These are:
.gvmi image is started by the VM runtime, an empty host directory is mounted under each of its directories declared as volumes (
VOLUME command in the
If there was anything stored in the image under the volume directory it gets "shadowed" by the mounted host directory.
In a running Golem VM, the storage space outside of volumes (declared through Docker's
VOLUME command) is limited to
128 MB of size stored in RAM using
This only applies to files created once the VM is running. Anything that was included in the image during the build process stays available (the VM's filesystem is an overlay).
Any larger files and chunks of data should be transferred to the VM's volumes. Since these directories are mounted from the host operating system they are only limited by the provider's storage space.
In general, it's better to test the
.gvmi image itself rather than the base Docker image. This guarantees that all Golem-specific conditions (filesystem characteristics, for example) are included. Also, testing with the VM runtime is as close to the provider's environment as possible.
You can learn more about testing the VM runtime locally in the Testing a Golem image article.
This is related to the answer given to "My VM has run out of storage space".
There you are two options here:
If the files are static (that is: they are always the same) then you can include them in the VM image itself while building it. You can learn more about that in Creating a Docker image.
If the files are dynamic (that is: they may differ between task executions) then your best option is to transfer the files from the requestor agent. Make sure you use a volume directory as the destination.