VirtConsole 3.2.3.3 is a patch release for both the management server and the hypervisor agent. It closes out a round of admin API work, and it adds the one capability that round kept asking for: a way back into a guest that no longer boots.
Rescue mode
Every KVM instance now has a Rescue action in the panel and on both APIs. Entering rescue power-cycles the guest into a small Debian 13 live system on the platform’s rescue ISO, with the instance’s own network configuration applied and a fresh root password shown in the panel and returned by the API for as long as rescue is active. The original disk is attached untouched, so you can mount it, repair a bootloader, reset a forgotten password or copy data off. Leaving rescue restores the previous boot order and clears the password. The rescue ISO comes from the image catalog like any other OS, so hypervisors fetch it on first use.
Load balancers and certificates
A Let’s Encrypt certificate issued through a load balancer now attaches itself to that load balancer’s HTTPS listeners as soon as it is issued, instead of sitting in the certificate list waiting for a manual attach. Issuance also survives an existing certificate lineage on the node: a renewal that is not yet due is treated as the success it is. System-managed HTTP listeners show their always-on HTTPS redirect for what it is rather than as a toggle that cannot be switched.
Operations
The updater and a daily check now verify that every PHP extension the platform needs is present and that the Debian PHP package repository key is still valid, and can install or refresh what is missing. The RustFS command-line client that S3 administration depends on is installed automatically when it is absent, at a pinned version. S3 server status refresh no longer stops at the first server that fails to answer.
Image catalog
Oracle Linux 9 and Oracle Linux 10 join the catalog as 10 GiB cloud images with cloud-init and the guest agent ready, alongside Fedora 44.
Rescue mode needs the Slave agent 3.2.3.3 on every hypervisor. Update it from the panel’s Update agent action before offering rescue to users.
API changes
The admin API (/api/v1) now wraps every response in one envelope, {success, data, meta, message, errors}, with a new X-Api-Envelope: v1 header on every answer, instead of the mix of bare models, bare lists and hand-built resource keys it used to return.
Paginated admin API lists now put their rows under data and their pagination fields under meta, rather than mixing pagination fields in at the top level next to the rows.
Impersonating a user now returns the token under data instead of at the top level, matching the envelope above.
A failed admin API request now answers with a real 4xx status code (with a new X-Failure-Status-Mapped header marking the rewrite) instead of HTTP 200 with "success": false in the body, which many HTTP clients used to treat as a success.
Instance payloads now include a machine-readable state field, the console proxy requires a short-lived session token, and hostname fields across the API are validated by one consistent rule instead of three that used to disagree with each other.
None of this was announced anywhere when it shipped, which broke integrations that were exercising the admin API against 3.2.3.3. We are sorry for that, and every shape change from here on ships with a changelog entry in the same release. See the full list, with before and after examples for each change, at docs.virtconsole.com/api/changelog.
Thanks for building on VirtConsole. Questions or trouble along the way, reach us any time.