A reusable SolusVM 2 operating-system image should produce a fresh, independently identifiable server every time. Build from a supported vendor image or the documented SolusVM image-builder workflow. Copying a live customer disk can duplicate credentials, private data and network identity.
IN THIS ARTICLE
What you need before you begin
Choose the supported distribution, architecture, filesystem, firmware and disk driver. Verify the original image source and checksum. Use an isolated build environment and retain the build recipe so the image can be recreated after security updates.
01 Prepare a reusable operating-system image in SolusVM 2
- Prepare the image with the current SolusVM OS Image Builder or another explicitly supported image process. Include the required boot drivers, networking and cloud-init integration for the intended guest.
- Remove build credentials, application data and reusable secrets. Follow the image-building tool guidance for machine identity, SSH host keys and first-boot state; do not indiscriminately clean a running production server.
- Publish the finished image at a controlled download location and record its version and checksum. Treat image replacement as a release, not an invisible change to an existing filename.
- In Images > Operating Systems, add the image/version and select compatible firmware and disk-driver defaults. Restrict availability to a test plan initially.
- Create two independent test servers. Confirm both boot, receive their own networking and access credentials, grow their disk as intended and complete initialization without inherited customer material.
Does a new image update servers already running?
No. Existing guests need their own patch-management process. Image defaults affect new deployments and relevant reinstall operations, which must be treated as destructive to existing guest data.
Confirm the expected result
Compare machine identifiers and SSH host keys between the two guests. Test console access, restart, package updates and the planned backup workflow. Confirm the selected filesystem and virtual hardware match SolusVM support requirements before making the image generally available.
Troubleshoot unexpected results
If deployment fails, examine the provisioning task and guest console. Firmware mismatch, missing storage drivers and incomplete cloud-init setup require different fixes. Withdraw a defective image from new provisioning and publish a corrected version; changing image defaults does not retrofit existing servers.