VirtConsole 3.3.1 is a patch release for both the management server and the hypervisor agent. Its headline is age-based backup retention for backup policies. It also refreshes Web SSH and makes several everyday operations more consistent with the API documentation.
Age-based backup retention
Backup policies can now keep backups by age instead of by count. Choose Keep by age (daily, weekly, monthly, yearly) as the retention type and set any of these rules: keep last, keep within a number of days, keep daily, keep weekly, keep monthly and keep yearly. Each calendar rule keeps the newest backup of each of the most recent periods that have one, and a period already covered by a kept backup is skipped, so every rule reaches further back. Rules run in the order Proxmox Backup Server prunes, and keep within days is a window on top of the others. At least one rule must be above 0, and the caps are 365 for last and daily, 3650 for within days, 520 for weekly, 120 for monthly and 30 for yearly.
The rules apply to Proxmox Backup Server destinations and to local, S3 and rclone destinations alike. On a Proxmox Backup Server destination each snapshot is judged on its own; on file destinations each disk is handled on its own, and a kept backup also keeps its full backup and every earlier incremental. Protected backups are always kept and do not use up a slot. Days, weeks, months and years follow the policy owner’s timezone, or UTC for provider policies.
Old backups are pruned automatically, and the owner receives a new Backups Pruned email when age-based retention removes some. The same choice is in the admin and user panels and on the admin and user APIs, as a retention mode (count or age-based) plus the six keep rules. Existing policies keep their number-based behaviour, with one refinement: count retention now applies per disk, so an All disks policy keeps its retention count for each disk.
Web SSH, refreshed
Web SSH sessions return a secure WebSocket address with a one-time token in its path, plus the time until it expires. The token works once and lapses after 15 minutes. Errors are now specific, with a 409, 422 or 503 status and a reason. KVM guests need the QEMU guest agent, because the platform injects its SSH key through it. The in-panel updater now tests the web server configuration and reloads nginx gracefully at the end of an update, so new web server settings take effect with no manual step. If the test does not pass, nginx keeps the previous configuration and the reason goes to the application log.
Images and ISOs
Adding an image from the catalog stores its real file size, or refuses with a clear reason when none is known. Images stored without a size are now filled in from the live catalog by the five-minute sync. Media transfers that keep running into errors now back off per node and per file, from 10 minutes up to 24 hours, and admins see the error on the Images and ISO lists with a Retry download action, which is always available.
ISO creation returns the new id and refuses non-https URLs and unsafe file names up front, and inserting an older http ISO on a KVM node is refused too. Eject detaches the media and never deletes the library record. An insert that cannot complete now ends its task with the node’s own message.
TPM, backups and instance controls
Enabling TPM is refused with a reason unless the KVM node confirms swtpm support, and migration, failover and rebuild never place a TPM guest on a node that cannot run it. A KVM node reports TPM support only once it runs the 3.3.1 agent, so until then these operations will not choose it for a TPM guest. New Debian and Ubuntu nodes get swtpm installed during provisioning; an existing Debian or Ubuntu node needs a one-time apt-get install swtpm swtpm-tools. The TPM and Secure Boot switches take effect at the next start.
On KVM nodes, deleting a backup no longer blocks other actions on the instance, and a bulk delete of several backups of one instance sends every row. Backup rows show which snapshot an incremental was based on, and restore tasks say which backup they came from.
Creating an instance can now set VNC access, and updating one can set the VNC keymap and protection.
Operations
Creating a hypervisor requires a hypervisor group, answers 200 with the new id, and always leaves a complete record for the linked node.
Two things to know: the panel settings save now validates the VNC allowed sources list entry by entry, so a master with an older invalid value there should update it before saving settings, and the database update for this release adds task indexing, which can take a little while on large installs.
API changes
The image list accepts a purpose filter, image update changes just the fields you send, subnet availability counts use one consistent rule everywhere, and admin user updates require real values for limits. Every change, with before and after examples, is listed at docs.virtconsole.com/api/changelog.
Thanks for building on VirtConsole. Questions or trouble along the way, reach us any time.