Cockpit Release Notes

This log tracks updates, new features, and bug fixes added to the Cockpit dashboard.

---

Version 3.3.2 (October 2026)

Read-only accounts can no longer download a Kubernetes cluster's credentials, a host can be removed while DRS is enabled, adopting distributed networks goes by network name, and the Tasks panel keeps following a clone after Cockpit reconnects to its host.

Security:

• Read-only accounts could download Kubernetes cluster credentials. In Cockpit 2.0.0 to 3.3.1, any signed-in account, a Read-only one included, could download a provisioned cluster's kubeconfig, and from 2.1.0 also the private SSH key of its node VMs. Either one gives full control of the cluster. Downloading them now needs the VirtualMachine.GuestOperations.Execute privilege, which the Administrator role has and Read-only does not. If Read-only accounts were given to people who should not control your clusters, treat those clusters' credentials as exposed. See Kubernetes.

Enhancements:

• Adopting distributed networks goes by network name. A network is proposed for adoption when at least two hosts carry a network with the same name on the same bridge. The Adopt dialog lists the networks on a bridge with the hosts that carry each, and the distributed network takes the chosen network's name. Before, two networks on one bridge could be paired across hosts and one of them dropped. A bridge that hosts carry under different network names is reported as a name mismatch rather than left out without a word.
• Only bridge-mode networks can be adopted. That means a libvirt network in bridge mode on an uplink bridge, Linux or OVS. Macvtap networks, OVN logical switches and network modes Cockpit does not recognise are refused. Isolated networks, which were shown as NAT, are now shown as Isolated.
• Migrating a VM on a bare bridge asks once. A VM attached to a bridge that is not part of a distributed network now gets a network mapping confirmation when it is migrated or evacuated. The dialog preselects the bridge of the same name on the destination.

Fixes:

• A host can be removed while DRS is enabled. In Cockpit 3.1.0 to 3.3.1, removing a host failed with a foreign key error (fk_drs_recommendations_target_host) when DRS had a pending recommendation involving the host or one of its VMs. Those recommendations are now removed with the host.
• The Tasks panel keeps following a clone after a reconnection. When Cockpit lost its connection to a host while a clone was running there, the clone's task stopped updating after the connection came back, even if the clone finished or failed in the meantime. Cockpit now subscribes to the clone again on reconnecting and picks up its current state.

---

Version 3.3.1 (September 2026)

Cloning a VM and deploying one from a template now ask what the copy's guest identity should be, so a clone no longer comes up with its source's DHCP address — or, for a cloud-image VM, with no network at all. The reset itself is done by the host, so upgrade Vapor on your hosts to 3.3.1 before, or together with, Cockpit.

New Features:

• Guest identity on Clone and Deploy from Template: The Clone Options step offers Reset guest identity (recommended) — a new machine ID, new SSH host keys, network settings bound to the clone's own MAC addresses, and the clone's name as its hostname — or Keep an exact copy. The wizard asks the host whether it can reset, previews the resulting hostname, and selects Keep an exact copy with the reason when the host cannot. The Tasks panel shows Resetting guest identity… while the host works, and Completed with warning when the clone finished with something you must know, such as a static IP address kept from the source. A reset asked of a host whose Vapor cannot perform it is refused rather than turned into a silent copy: upgrade Vapor on that host to 3.3.1. API clients pass guest_identity to POST /api/v1/vms/{id}/clone and POST /api/v1/vms/from-template, and GET /api/v1/vms/{id}/clone-capabilities says whether a VM's host can reset. See Virtual Machines.

Enhancements:

• GET /api/v1/datastores/{id}/volumes/{vol_name}?inspect=true passes on the host's verdict on whether a file is self-contained, before it is offered as an image. A host older than Vapor 3.3.1 answers "inspection": null, which is not a pass.

Fixes:

• A snapshot delete or revert that the host refused showed a raw error, and a failed delete stayed "processing" in the Tasks panel. The dialog now shows the host's reason — VM must be shut off when the delete needs the VM stopped — and the task is closed as failed.

---

Version 3.3.0 (September 2026)

Cockpit brings Open Virtual Network to the datacenter: activate OVN across a datacenter's hosts from one wizard, attach VMs to OVN logical switches, and move stopped VMs between OVN deployments. Templates get a view of their own, Enter Maintenance handles paused guests and shared storage properly, and Edit Settings knows what can change on a running VM. Much of this relies on Vapor 3.3.0, so upgrade Vapor before, or together with, Cockpit.

New Features:

• Virtual Network (OVN) per datacenter: A datacenter's Virtual Network tab activates OVN on all of its hosts in one of three modes: a Vapor-native deployment (1, 3 or 5 central hosts forming a clustered database, the others as chassis), an existing external OVN, or an existing Kube-OVN cluster — where only hosts that are Kube-OVN nodes with the OVN client tools take part, and the others are listed as excluded with the reason. Preflight measures the tunnel path between every pair of hosts and warns when it cannot carry full-size guest frames. A would-be central's existing standalone OVN databases are replaced only when you confirm it for that run. A host added to the datacenter joins as a chassis, and a deployment that only partly succeeds offers Retry failed hosts. Host > Configure > Networking > Virtual Network shows a host's own state.
• VMs on OVN: A VM's network interface can sit on an OVN logical switch, in the VM wizard and in Edit Settings. A stopped VM with OVN interfaces can be migrated to a host in another OVN deployment.
• Template view: A template's tab shows the template itself — guest OS, firmware, CPU, memory, disks and network adapters — instead of a placeholder card, with Deploy VM, Clone to Template, Convert to VM, Rename and Delete actions, and a VMs tab listing the VMs deployed from it.
• Editing a running VM: Edit Settings shows what applies live, what waits for a reboot and what needs the VM stopped. Firmware, architecture, machine type and PCI passthrough are locked while the VM runs, Name is disabled, and each network adapter's link can be brought up or down on the spot.

Enhancements:

• New VMs default Max vCPUs and Max Memory to the host's CPU count and memory, so vCPUs and memory can be hot-added later; memory fields default to GiB.
• The VM summary shows the operating system the guest agent reports when the VM's definition names none.
• The inventory tree marks hosts that are in maintenance or disconnected.
• The datastore Files tab shows the selected item's full name, its path in the pool with a Copy path button, its size, format and modification time.
• A datastore upload that the host refuses — an image that reads other files, a file name that is not a plain name, a checksum mismatch — shows the host's reason instead of failed to commit file for browsing.
• A network interface's source list follows its type: libvirt networks for Network, logical switches for OVN, the host's Linux and OVS bridges for Bridge. The Kubernetes wizard offers only distributed networks as the target network.
• With Overwrite existing VM, the restore dialogs hide the new-name field and warn that the VM will be stopped and replaced and stays powered off afterwards — emphasised when it is running.
• VMs created from Oort have their own icon in the inventory.

Fixes:

• Saving a UEFI VM's settings no longer strips them. Edit Settings opened with Enable UEFI, Secure Boot and TPM unchecked and the CPU settings at their defaults, because the VM detail response left them out — and saving from that state would have removed them. The CPU options migratable and cache were also dropped on save.
• Restoring a backup through Cockpit no longer times out after 30 seconds with an error while the host carried on restoring. With Vapor 3.3.0 a backup can be restored over the VM it came from, all disks included.
• A planned failover shuts the source down gracefully. It asked the host for an action the host did not accept, so the graceful stop always failed and every planned failover powered the source off hard. The action API's shutdown and reboot, and the oVirt-compatible API's suspend, now reach the host as actions it runs.
• HA fails a VM over only to a host that can reach its datastores. It could pick a host whose shared datastore was not mounted; attaching the disk failed and the failover retried the same host without end.
• Enter Maintenance evacuates paused VMs as well as running ones; before, a host could be marked safe with paused guests still on it. It asks the host itself which guests remain instead of an inventory that lags behind, runs at most two migrations at a time with only one copying storage, stops with Retry storage shutdown or Mark maintenance anyway when shutting down OCFS2 storage fails instead of marking the host regardless, and offers the host's cluster mates as destinations rather than any connected host.
• A VM converted to a template, or a template converted to a VM, did not appear in its new place in the sidebar until the next sync, and a tab already open on it kept showing the old view.
• A VM that briefly disappeared from its host — as during an in-place restore — came back as a new inventory entry, which broke open tabs and links. It now keeps its identity.
• A host sync that reported no metadata for a VM, or a resize, erased the VM's metadata — the stamp that marks, for example, a Kubernetes node or a VM created by another product.
• The VM summary showed 0 GB for a disk whose size the host reports as capacity, the replication target list showed Available: n/a, and the datastore Summary showed Used 0.0% beside real usage.
• Resizing a volume in the datastore browser started from the file's size on disk instead of its virtual size.
• Change Password stayed disabled when a password manager filled in the fields.
• Several identity sources could all be marked Default, so a login without a domain landed in whichever one the database returned first. Seeding now hands the default over, and the upgrade repairs an installation that already has several, keeping the most recent.
• A new Kubernetes cluster whose nodes cannot reach the internet was reported with a failed local-path storage tier although its storage worked. Cockpit now uses the local-path storage that k3s already provides.
• An in-app update on an installation with the hardened service unit failed mid-download with read-only file system. Add ReadWritePaths=/usr/local/bin to the cockpit unit and run systemctl daemon-reload && systemctl restart cockpit, or update with scripts/cockpit-manual-update.sh. From 3.3.0 the update checks this before downloading and says what to do.
• Licence and TLS certificate dates are written with the month spelled out, so a date such as 10/9/2026 can no longer be read as two different days.

---

Version 3.2.0 (September 2026)

Cockpit can now recover a whole site at its surviving partner, restart a failed host's VMs only after fencing it, and hold a migrated guest's disks in a folder of their own. Kubernetes clusters gain multiple worker pools and storage that actually comes up.

New Features:

• Two-site disaster recovery: A workload recovers at the surviving site under the identity it already had — its libvirt UUID travels with it, so the recovery plan finds the same VM rather than a copy of it. Site pairing takes an API access token ID and secret.
• Cluster HA that fences first: A failed host's VMs are restarted only after the source has been fenced, and the evidence of that fencing is recorded. Restarts keep the guest's own specification, map disks to VMs explicitly instead of matching filenames, and are placed through resource scheduling. The HA scheduler only acts on the control plane that holds leadership.
• A guest's disks in a folder of their own: A datastore can place a migrated guest's disks in a directory named after it, follow that download by its job — a file in a directory appears in no pool listing, so nothing else could report it finished — and delete it again where it actually landed.
• Forward the caller's certificate authority: A download the fleet relays carries the caller's own certificate authority through to the host, so a source with a private certificate needs nothing installed anywhere.
• Adopt existing cluster networks as distributed: Networks already present on the hosts can be taken over as distributed networks rather than rebuilt.
• Kubernetes node pools: Multiple worker pools, per-pool CPU configuration, labels and taints, a table view with add and remove, and prefill from wherever the wizard was launched.
• Per-node upgrade visibility: A cluster's Tasks tab shows each node's upgrade job and its logs.
• Interface type on migration mappings: A VM's network mapping can name a bridge or direct target, not only a virtual network.

Enhancements:

• Longhorn is configured by replica count, validated against the node pool size, instead of a datastore picker that could ask for more replicas than there were nodes.
• Node lists and cluster detail keep up with what is happening rather than needing a reload.

Fixes:

• Longhorn works. Node prerequisites are installed, the health check has a realistic window and no longer passes before storage is ready, there is a single default storage class, replicas stay off control-plane nodes, and replicas are evicted before a node is removed instead of being stranded by a timed-out eviction.
• A failed-over VM's inventory entry flips when the failover is confirmed, not when it is dispatched.
• A migration certificate that does not name the host's address is caught before the transfer, not during it.
• An explicit CPU topology is sent with max_vcpus, so it actually applies.
• Deleting a Kubernetes cluster no longer orphans VMs that were still being provisioned.
• An upgrade's progress is read from pod counts correctly rather than failed-first, and the control plane is upgraded properly.
• The NFS CSI tier reports its own installation failures instead of being assumed present, and its inputs no longer reach a shell.
• Empty lists are sent as JSON arrays rather than null, which used to crash the UI.
• More than one component can listen to the same channel, and a newly created object appears in the list without a reload.

---

Version 3.1.0 (August 2026)

Cockpit gains a scheduler that keeps a cluster balanced on its own, a wizard for moving VMs between hosts and datacenters, and a search box that finds anything in the inventory.

New Features:

• Distributed resource scheduling: Keep a cluster balanced with affinity and anti-affinity rules, recommendations you can review before applying, and host evacuation for maintenance. When the scheduler is not acting, it now says why instead of reporting the cluster as balanced.
• Migration wizard: Move a running or stopped VM to another host, with a compatibility check before it starts, a bandwidth cap, and the option to cancel while it runs. A migration that crosses a datacenter boundary is shown as such, and the storage rule for it is enforced.
• Search the whole inventory: One box in the header finds any VM, host, or cluster — including by the UUID from a log or a ticket — and opens each result wherever it lives.
• Rename a VM: Rename a stopped VM from the inventory. The action stays unavailable while the VM is running.
• Asynchronous failover: A failover returns straight away and its progress is polled, so a long recovery no longer ties up the console.
• Kubernetes node metrics: The node list shows vCPU, memory, and live CPU and memory usage, and cluster detail updates as it happens.

Enhancements:

• Tasks and events are attached to the object they concern, so a VM's own page shows what happened to it, and cluster-level Kubernetes tasks appear on the cluster page.
• A running template job can be cancelled, and a cancelled job is reported as finished instead of processing forever.
• Add a member node to a shared storage group across hosts, and see whether each node's kernel is in sync.
• The VM list shows each VM's host, operating system, and IP address.
• Exporting a VM list to CSV carries each VM's host, operating system, and IP address.
• The task and event lists can be filtered from each column's own header.
• Replication is configured in a dialog, with a note about the guest agent a quiesced copy needs.

Fixes:

• Cockpit no longer reports "Up to date" when an update is available.
• An unplanned failover could be routed to the wrong host, and a second failback cycle could send a VM back to a site already running it.
• Enrolling a VM in replication did not start its first baseline copy.
• A VM's total disk size counted CD-ROMs, read-only disks, and attached ISOs.
• Cloning a VM ignored the storage pool and full-clone options that had been asked for.
• Each host now shows its own backups rather than those of the host opened last.

---

Version 3.0.2 (August 2026)

Cockpit now drives disaster recovery across sites from one console: choose what is protected and where it goes, watch it replicate, and run the failover when you need it.

New Features:

• Disaster recovery across sites: Choose which VMs replicate to which site, follow their progress, and run a planned failover that shuts the source down cleanly, ships the final changes, and boots the VM at the recovery site.
• Reprotect: One action turns a recovered VM back into a protected source, replicating in the opposite direction.
• Replication settings on the VM: Set how often recovery points are taken and how long they are kept, choose which disks are included, request a quiesced copy, and pause or resume protection.
• Backup and restore over the oVirt-compatible API: Backup tools that speak oVirt can now run backups and restores against Awanio, and read a VM's console and network devices.
• Update from a direct download: Point Cockpit at a binary URL and its checksum when it cannot reach the update service.

Enhancements:

• Replication runs a limited number of transfers at a time, so protecting a large group does not saturate the link.
• Replication history records the bytes actually transferred.

Security:

• The oVirt-compatible API did not verify the credentials on incoming requests, and did not slow down repeated failed logins. Versions 3.0.0 and 3.0.1 are affected; upgrade to 3.0.2.

Fixes:

• A planned failover no longer risks running the same VM at both sites. Cockpit confirms the source is down before booting at the recovery site, and stops with a clear error rather than proceeding when it cannot.
• Cancelling a planned failover after the source had already stopped used to leave it down; it now rolls back and starts the source again.
• A VM could be enrolled in replication more than once.
• Replication status was read from the wrong layer of the response and could appear unavailable.
• An update check could fail to find the version that had been published.

---

Version 3.0.1 (July 2026)

Adds warm migration support for Cockpit-managed hosts.

New Features:

• Warm migration target: A Cockpit-managed host can now be the destination for a live, minimal-downtime migration of a running VM — the guest stays online during the transfer. Together with Condensa and Vapor, this brings running Proxmox VMs into Awanio.

---

Version 3.0.0 (July 2026)

A major release focused on fleet-scale automation and a hardened, fail-closed security posture. It adds Kubernetes cluster provisioning, automated load balancing and failover (DRS/HA), clustered shared storage, and one-click import from other virtualization platforms.

Breaking change — action required

This release fails closed: Cockpit will not start or authenticate without a configured signing secret, and every change now goes through default-deny permission checks. Set your JWT secret and review role assignments before upgrading.

New Features:

• Kubernetes Provisioner: Build and manage whole Kubernetes clusters from Cockpit. Nodes are placed with awareness of each host's spare capacity, scaled up or down safely (with automatic drain and cordon), and given either fixed (static) or automatic (DHCP) addresses. Cluster bootstrap now runs through the guest agent instead of SSH, and node VMs are protected from accidental deletion.
• Automatic Load Balancing & Failover (DRS/HA): Cockpit can keep VMs and their affinity rules balanced across hosts, honor per-VM placement overrides, and follow VMs as they move between hosts.
• Clustered Shared Storage (OCFS2): A guided Shared Group workflow sets up and operates an O2CB cluster — heartbeat modes, maintenance mode with safety pre-checks, and cross-host drift detection — so several hosts can safely share the same datastore. Large datastore builds now run in the background with progress in the Tasks panel.
• Import from Other Platforms: Warm and cold disk imports (VDDK) are surfaced in the Tasks panel, with Veeam and Vinchin integration through the oVirt compatibility shim.
• Differential Backups: Choose a parent backup to build space-efficient differential chains, with storage-pool targeting.
• Signed In-Place Updates: Cockpit can update its own binary from a signed release channel.

Enhancements:

• Consistent VM deletion: Deleting a VM from the inventory tree now behaves exactly like the VM tab — it powers off first when needed, optionally removes disks, and actually deletes the VM on the host.
• Friendlier error handling: Blocking browser pop-ups have been replaced with inline messages and non-blocking toast notifications throughout inventory management.
• Identity-preserving migration: When a VM moves hosts, its inventory record (and the permissions attached to it) is relocated in place instead of deleted and recreated. "Undefine source" is the default, with a clear risk acknowledgement.
• Safer VM specs: CPU topology is validated against the maximum vCPU count, and disk sizing is available when cloning.
• Lighter footprint: Per-VM metric updates are scoped to reduce load, and host heartbeats retry faster to avoid lease expiry.

Security:

• Fail-closed authentication with algorithm pinning, authenticated console sessions, and CORS/path hardening.
• Default-deny permissions that correctly honor object-scoped (inherited) admin grants.
• Encrypted control channel between Cockpit and hosts with certificate pinning, plus rate-limiting on login endpoints.
• Password policy enforcement and self-service password change.
• Kubernetes join-token seed files are removed from storage after bootstrap.

Bug Fixes:

• Permission checks now honor object-scoped admin grants.
• Cloud-init seed removal is reboot-safe, and Kubernetes nodes boot reliably on physical hardware.
• Kubernetes cluster view shows human-readable network names.
• OCFS2 cluster reuse retries robustly with an extended timeout.
• Datastore wizard preserves storage fields and filters LUN eligibility correctly.
• VM backups resolve the correct disk identity, with longer timeouts for large jobs.

---

Version 1.2.0 (May 2026)

New Features:

• Shared Storage Support (Clustered Storage): You can now connect your servers to shared network hard drives (using NFS, iSCSI, or Fibre Channel). This allows multiple physical servers to read and write to the same storage space.
• Shared File Systems (OCFS2 & o2cb): Added tools to configure OCFS2 (Oracle Cluster File System). This acts like a shared Google Doc, allowing multiple servers to edit files on the same hard drive at the same time without overwriting each other's data.
• Smart Migration Checks: Cockpit now automatically detects if a virtual machine's disk is on a shared network drive. If it is, Cockpit speeds up the live migration process by only copying the VM's active memory, skipping the long disk-copy phase.

Bug Fixes:

• Fixed intermittent security certificate errors that occurred when migrating VMs between servers.
• Optimized the background host claimant system to reduce database load.

---

Version 1.1.0 (March 2026)

New Features:

• Single Sign-On (SSO): Added support for logging into Cockpit using your company's central account systems, including Active Directory (AD), LDAP, and SAML 2.0 (like Okta or Azure AD). You can also configure passwordless login for Windows computers (Kerberos).
• High Availability Database: Validated that Cockpit runs smoothly with Patroni PostgreSQL databases. This ensures that if your main database server crashes, a backup database takes over instantly without interrupting Cockpit.
• Centralized Log Archiving: Added support for streaming Cockpit's audit logs to external security monitoring systems (using the standard RFC 5424 Syslog format).

Bug Fixes:

• Fixed a memory leak in the WebSocket Event Hub that occurred when users closed their browser tabs quickly.