Side-Load Workload Images
Build a reusable appliance under STRATUM, promote it into Arsenal, then side-load the complete promoted image directory when an Enterprise/support-guided deployment requires content outside the normal Arsenal lifecycle.
What side-loading is — and why it is different
Normal STRATUM deployments should use Arsenal. Side-loading directly modifies packaged application content inside the running STRATUM container and is therefore intentionally outside the standard supported workflow. It is useful for specialized appliances and integration work, but it can also bypass validation and lifecycle protections that Arsenal normally provides.
Need the content embedded in a distributable STRATUM release? Use STRATUM Container Appender to package the approved disks and templates into a versioned image before deployment, instead of copying them into a running container.
Files copied only into the current STRATUM container are not durable across container replacement. An upgrade, container deletion, or reinstall can remove those additions. Enterprise customers should use this workflow only with a deliberate persistence plan or under Thinking Datacenters guidance.
The safest way to build side-loaded content is to create the appliance inside STRATUM first, on the same virtual hardware you intend to ship. That proves the operating system, firmware state, disk bus, NIC model, and console path before the image is packaged.
Build and prove the image under STRATUM
Install the appliance with its shipping hardware profile
For a VyOS example, create the VM with the hardware you intend to keep: STRATUMVMM, UEFI, VirtIO block storage, VirtIO NICs, and serial console. Boot the installer ISO and install VyOS onto the writable VM disk.
Remove installation media and prove a standalone boot
Eject the ISO, reboot the VM, and verify that the installed appliance boots correctly under STRATUMVMM without the installer attached. This is the point where firmware/boot state problems should be found—not after the image has been distributed.
Shut the VM down completely
Promotion should start from a clean stopped workload. Confirm the appliance is powered off before promoting it into Arsenal.
Promote the VM into Arsenal
Open Arsenal → VM Images → Promote VM, select the stopped appliance, and promote it with a release-oriented name such as vyos-1.5.0. Promote VM is the key step: STRATUM converts the VM's writable QCOW2 overlay into a flattened standalone QCOW2 image rather than leaving the promoted image dependent on the original base chain.
stratumimg convert -f qcow2 -O qcow2 <VM-overlay> <new-image>Keep the STRATUMVMM VMGS with the disk
For a typical first VirtIO block disk, the promoted image directory contains the flattened virtioa.qcow2 and, for STRATUMVMM, stratumvmm.vmgs. Depending on the engine and enabled features, the image directory may also contain UEFI variables, firmware metadata, or TPM state.
Do not extract only the QCOW2 and discard the VMGS file. STRATUMVMM uses VMGS as persistent Microsoft VM firmware state. It can contain UEFI boot identity/state that the installed appliance depends on. STRATUM captures the workspace VMGS during promotion and seeds new deployments from the VMGS stored beside the promoted disk.
vyos-1.5.0/
├── virtioa.qcow2
└── stratumvmm.vmgs
Potentially also:
├── uefi-vars.fd
├── uefi-firmware.json
└── tpm2/Export and inspect the Arsenal bundle
A .stratumarsenal bundle is a ZIP archive. When a VM Image is exported, STRATUM recursively packages the VM-image directory beneath payload/vm-images/<image-name>/. That means the disk and its companion STRATUMVMM state travel together.
manifest.json
payload/
└── vm-images/
└── vyos-1.5.0/
├── virtioa.qcow2
└── stratumvmm.vmgsunzip -l vyos-1.5.0.stratumarsenal
unzip vyos-1.5.0.stratumarsenal \
'payload/vm-images/vyos-1.5.0/*'Copy the complete image directory into STRATUM
Stage the extracted image files in a local directory first, then copy the complete directory into the running STRATUM container. For this VyOS example, the production side-load path is /stratum/addons/qemu/vyos-1.5.0/.
mkdir -p vyos-1.5.0
cp payload/vm-images/vyos-1.5.0/virtioa.qcow2 vyos-1.5.0/
cp payload/vm-images/vyos-1.5.0/stratumvmm.vmgs vyos-1.5.0/
docker cp vyos-1.5.0 stratum:/stratum/addons/qemu/vyos-1.5.0Side-loaded files live inside the replaceable application container. If this content must survive upgrades, use an Enterprise/support-approved persistence method. One advanced option is to commit the modified container to a new image/tag and configure stratum-host to use that image. That is an application-image lifecycle decision, not ordinary Arsenal administration.
How the side-loaded image appears
Side Load Workload Image Directory
Keep the directory name aligned with the template that should expose the image and use the disk filename convention expected by that template.
Commands
Advanced inspection only; run inside the appropriate container if the image directory is there. The full image set, including VMGS where required, must remain together; see the persistence warning above.
# Example: inspect the complete side-loaded VM image directory
IMAGE_NAME=your-image-name
ls -l "/stratum/addons/qemu/${IMAGE_NAME}/"
qemu-img info "/stratum/addons/qemu/${IMAGE_NAME}/virtioa.qcow2"Template Name Matching
Refresh Arsenal after the files are present. The side-loaded image should appear under the matching workload template.
The outcome you should see
The promoted appliance is a standalone image set, its STRATUMVMM firmware state is preserved beside the QCOW2, and the complete directory is visible through the matching Arsenal template after side-loading.