OS templates and ISOs

OS templates

OS templates are the images customers install from. Templates are cloud images with cloud-init, which sets the hostname, network, login and first-boot script.

From the OS catalog

OS templates → Add from catalog lists ready-made Linux cloud images, each from its own distribution. Click Add next to one and it’s imported like any other template.

• Where it comes from: each node downloads the image from the distribution’s own servers. Nothing passes through the panel.
• Checksums: the panel reads the image’s checksum from the distribution’s checksum file when you add it, and every node checks its download against it. You don’t type one in. Debian publishes SHA-512 checksums only, so Debian images are checked by their SHA-512.
• Newer builds: distributions replace these images with patched builds now and then. Re-sync on a catalog image reads its checksum again and copies the newest build to every node. Servers already installed from it aren’t touched.
• Firewalls: the controller has to reach the distributions’ websites over HTTPS to read checksums, and the nodes to download images.

If a node reports a checksum mismatch for a catalog image, the distribution has published a newer build since it was added: Re-sync it.

Adding one by its link

OS templates → Add by link, for images that aren’t in the catalog:

Lifecycle

A template imports as hidden; Publish it once it’s on every node. Hiding a published image keeps it cached for servers already using it. A published template has to be hidden before it can be deleted.

Windows Server

Microsoft doesn’t publish a ready-made cloud image, and converting the ISO to qcow2 isn’t enough: the ISO is an installer, not an installed system. The panel has a script that installs Windows in a temporary VM on a node and turns the result into a template. It:

• installs Windows unattended, with the VirtIO disk and network drivers;
• installs the VirtIO guest tools and the QEMU guest agent (password resets, disk usage and snapshots in the panel);
• makes sure the Balloon driver and service are in (they come with the VirtIO guest tools; added from the ISO if not), so servers from the image show their memory use on their page;
• installs cloudbase-init, which reads the panel’s first-boot settings the way cloud-init does on Linux;
• lets ping through the Windows firewall (Remote Desktop is turned on by each server’s first boot instead: on in the image, Server 2025’s Setup crashes);
• generalises Windows with sysprep, so each server gets its own identity;
• compresses the disk and prints its SHA-256.

On first boot each server gets its hostname while Windows Setup runs; once Setup has finished, cloudbase-init gives it the Administrator password the panel generated, its IP addresses (Windows doesn’t use DHCP here), Remote Desktop on, Administrator lockout off, and C: grown to the package’s disk size. Server 2025 locks the built-in Administrator out after 10 failed sign-ins by default; with Remote Desktop open to the internet, password-guessing bots would lock customers out of their own servers, so the panel sets Allow Administrator account lockout to off (the image has it off too). Other accounts keep Windows’ lockout policy. It waits for Setup on purpose: a restart in the middle of Setup ends in “The computer restarted unexpectedly”. Windows servers always get a password, even if SSH keys were picked.

Building the image

1. Download the Windows Server 2025 ISO from the Microsoft Evaluation Center (English, 64-bit ISO, about 6 GB) and copy it to a node, e.g. /root/windows-server-2025.iso. A retail or volume ISO works too; pass its key with --key.
2. On the node, as root, run (swap in your panel’s address): curl -fsSL http://<your panel>/agent/build-windows-image.sh | bash -s -- --iso /root/windows-server-2025.iso It takes 30–60 minutes and works in /var/lib/panel-agent/windows-build/. To watch the install, open a tunnel with ssh -L 5977:127.0.0.1:5977 root@<node> and point a VNC viewer at localhost:5977.
3. Copy the finished image to the controller’s image folder, /var/lib/panel/images/. The script prints the exact scp command.
4. OS templates → Add by link with the values the script printed: Distribution Windows Server, Version 2025, Download link http://<your panel>/images/windows-server-2025.qcow2, the SHA-256, and Minimum disk 40.
5. Once it’s imported on every node, Publish it.

Replacing an image with a newer build: delete the old template first, then add the new one. Nodes keep their copy of a template until it’s deleted, so changing the file alone isn’t enough. Servers already installed from the old one keep running.

Images in /var/lib/panel/images/ are only handed to the panel’s own nodes; anyone else gets 401. The evaluation edition runs for 180 days; license servers you sell with your SPLA or a retail key.

If the build stops with “The VM shut down before sealing”, the log from inside Windows says why:

virt-cat -a /var/lib/panel-agent/windows-build/disk.qcow2 /Windows/Panel/setup.log

Servers on Windows get Hyper-V enlightenments and a local-time clock by default; staff can change them on the server’s Hardware tab.

ISO library

Staff add installers under OS templates → ISO library:

The link is checked straight away. Nodes download and verify each ISO the first time it’s mounted. An ISO mounted on a server can’t be deleted.

Customers’ own ISOs and images

When switched on under Settings → Customer features:

• Custom ISOs: customers add an installer from an https link to an .iso on a server’s Settings tab. Up to 3 per account by default.
• Custom images: customers save a snapshot as an image and reinstall their other servers with it, in any location. Windows images are generalised with sysprep. A server can only use an image if its disk is at least as big as the source server’s. Up to 5 per account by default.

The limits are under Settings → Customer limits.