Here you can find how the OpenNebula's datastores and images are mapped to the StorPool Templates, Volumes, and Snapshots.
The addon uses the YY.MM.R versioning schema, where YY is the year of the release, MM is the month of the release, and R is the revision in the month.
Each Datastore in Opennebula has a StorPool template with the following format:
${ONE_PX}-ds-${DATASTORE_ID}Each persistent image registered in a StorPool-backed IMAGE datastore is mapped to StorPool volume:
${ONE_PX}-img-${IMAGE_ID}The non-persistent images are clones of a image registered in the IMAGE datastore mapped to StorPool volume:
${ONE_PX}-img-${IMAGE_ID}-${VM_ID}-${VMDISK_ID}The images of type CDROM are created like non-persistent images - cloned volumes with additional StorPool tag type=CDROM:
${ONE_PX}-img-${IMAGE_ID}-${VM_ID}-${VMDISK_ID}The volatile images are registered in the StorPool-backed SYSTEM datastore as a StorPool volume:
${ONE_PX}-sys-${VM_ID}-${VMDISK_ID}-rawEach contextualization image registered in a StorPool-backed SYSTEM datastore is mapped to StorPool volume:
${ONE_PX}-sys-${VM_ID}-${VMDISK_ID}-isoWhen the addon is configured in qemu-kvm-ev-backed flavor (SP_CHECKPOINT_BD=1), the VM's checkpoint file is a StorPool volume:
${ONE_PX}-sys-${VM_ID}-rawcheckpointWhen the default qemu-kvm package is used, the StorPool volume holding the archive of the checkpoint file has following name:
${ONE_PX}-sys-${VM_ID}-checkpointIn the process of importing of an image to a StorPool-backed IMAGE datastore, the source is stored temporary on a StorPool volume name suffixed with the md5sum of it's name:
${ONE_PX}-img-${IMAGE_ID}-${MD5SUM}${VOLUME_NAME}-snap${SNAP_ID}${VOLUME_NAME}-ONESNAP-${VMSNAPSHOT_ID}-${UNIX_TIMESTAMP}${ONE_PX}-sys-${VM_ID}-NVRAM