Vapor Release Notes

This log tracks updates, new features, and bug fixes for the Vapor host agent.

---

Version 3.3.2 (October 2026)

This release closes a security hole in SSH key sign-in that is present in every earlier version, so upgrade every host. It also accepts VDI and VHDX uploads again, lets hosts with an older kernel reset the identity of clones of running VMs, and stops long clones from failing at the end.

Security:

• SSH key sign-in accepted keys the user had not authorized. In Vapor 3.3.1 and every earlier version, signing in with an SSH key (POST /api/v1/auth/challenge, then POST /api/v1/auth/challenge/verify) checked the signature against the public key sent with the request, but not whether that key is one of the user's authorized keys (~/.ssh/authorized_keys). Anyone who could reach the Vapor API could therefore sign in as any user on the host, root included. Vapor 3.3.2 accepts only keys the user has authorized. Upgrade every host to 3.3.2; until then, let only trusted networks reach the Vapor API.

Fixes:

• VDI and VHDX images can be uploaded again. Vapor 3.3.1 refused them, although the storage browser's Convert action offers both as source formats. Upload them and convert them as before.
• Clones of running VMs on hosts with a kernel older than 5.15. On Ubuntu 20.04 (kernel 5.4), the identity of a clone of a running VM with a modern guest such as Debian 13 could not be reset (reason unmountable), and the clone usually started with no network. Clones of stopped VMs were not affected. A new installation on Ubuntu 20.04 now gives Vapor's libguestfs appliance a 5.15 kernel without changing the host's own kernel. On a host upgraded in place, set it up by hand: see Virtual Machines.
• Long clones no longer fail at the end. Vapor renews its libvirt connection every 30 minutes (since 3.0.0). A clone or a deploy from a template that was still copying disks or resetting the guest identity when that happened could fail after the copy, when the VM was being created. Vapor 3.3.2 keeps the connection until the VM is created.

---

Version 3.3.1 (September 2026)

A clone no longer carries its source's identity. Cloning a VM or deploying one from a template can now give the copy its own machine ID, SSH host keys and hostname, so it gets a DHCP address of its own, and a clone of a cloud-image VM comes up with its network. This release also repairs a 3.3.0 regression that created clones without the QEMU guest agent channel, and lets snapshots of UEFI VMs be deleted without leaving the VM unable to start.

New Features:

• Guest identity when cloning or deploying from a template: Clone and deploy-from-template now ask how to treat the copy. Reset guest identity (recommended) gives it a new machine ID, new SSH host keys, network configuration bound to its own MAC addresses, no DHCP leases, a new random seed and a hostname of its own. Keep an exact copy leaves it identical to the source, for restore tests or software licensed to the machine ID. Until now every clone was an exact copy: it received the source's DHCP address, and a clone of a cloud-image VM booted with no network because its configuration still named the source's network card. The reset works on the copied disks before the clone is defined; if it fails, the clone fails and nothing is left behind. Windows guests, encrypted disks and guests the host cannot mount are detected before anything is copied — clone those with Keep an exact copy. A static IP address is kept, with a warning, and the clone is created with autostart off so you can change the address before both VMs run on one network. API clients pass guest_identity (reset, auto or keep). See Virtual Machines.
• Host requirement for the reset: The reset uses the libguestfs tools. A new installation gets them. On a host upgraded in place, install them before cloning; until then the host offers only an exact copy:
  • Debian 12 and later, Ubuntu 22.04 and later: apt-get install guestfish libguestfs-xfs
  • Debian 11, Ubuntu 20.04: apt-get install libguestfs-tools libguestfs-xfs
  • RHEL 9 and rebuilds: dnf install libguestfs libguestfs-xfs
  • RHEL 8 and rebuilds: dnf install libguestfs-tools-c libguestfs-xfs

Enhancements:

• The disks of a newly created VM default to cache mode none and I/O mode threads unless the request sets them. Existing VMs are not changed.
• A snapshot delete that needs the VM shut off says so plainly — in the delete dialog and as 409 SNAPSHOT_REQUIRES_SHUTDOWN in the API — instead of a generic failure.
• A file already in a pool can be judged by the same rule uploads are: GET /api/v1/virtualization/storages/pools/{name}/volumes/{vol_name}?inspect=true reports whether it is self-contained, and if not, why — before it is offered as an image.

Security:

• An uploaded or downloaded image must be in a format volumes are kept in — qcow2, raw (an ISO counts as raw) or VMDK — and a VMDK must be a single file. A VMDK descriptor lists the files its data lives in, and any path on the host would do, so a descriptor, including a descriptor with a separate -flat file, is now refused. Upload a monolithic or stream-optimized VMDK, or convert the disk first, for example qemu-img convert -O qcow2 in.vmdk out.qcow2. QED and VHD images are refused as well; convert them to qcow2 first. VDI and VHDX are meant to be accepted — see Known Issues.

Fixes:

• Clones have the QEMU guest agent channel again. VMs cloned — or deployed from a template — with Vapor 3.3.0 were created without the channel the guest agent talks through, so the host could not reach the agent: the guest's IP addresses went unreported and backups could not freeze the guest's file systems. Vapor 3.2.0 and earlier are not affected, and clones made with 3.3.1 have the channel. A clone already made with 3.3.0 keeps the problem until it is repaired: shut it down, call POST /api/v1/virtualization/computes/{id}/guest-agent/channel, and start it again — or clone it again from its source.
• Snapshots of UEFI VMs can be deleted without breaking the VM. A UEFI VM with older snapshots taken while it was off and newer ones taken while it ran — as 3.3.0 allows — holds a chain that libvirt refuses to delete from either end. With the VM shut off, both kinds now delete; with it running, Vapor asks you to shut it down instead of returning libvirt's error. A snapshot delete could also leave the VM unable to start; a VM left that way is repaired the next time it is started from Vapor or Cockpit.

Known Issues:

• VDI and VHDX images are refused on upload. Vapor 3.3.1 refuses an uploaded or downloaded VDI or VHDX image, although the storage browser's Convert action offers both as source formats; Vapor 3.3.0 and earlier accept them. Until a release that accepts them again, convert the disk before uploading it, for example qemu-img convert -O qcow2 disk.vdi disk.qcow2 (or disk.vhdx), and upload the qcow2 file. Fixed in Vapor 3.3.2.

---

Version 3.3.0 (September 2026)

Vapor now manages Open Virtual Network: logical switches and routers, VPCs, security groups, DHCP and load balancing, with VMs attached to them like to any other network, and a wizard that activates OVN on a host or forms a new OVN cluster. A backup restores the whole VM — every disk and its configuration — and can overwrite the VM it came from. Memory snapshots work for UEFI VMs, and editing a VM no longer leaves it unable to start. Upgrade to 3.3.1: VMs cloned with 3.3.0 are created without the QEMU guest agent channel.

New Features:

• Open Virtual Network (OVN): Manage OVN from the OVN view under Network: logical switches and their ports, logical routers with static routes and NAT, a read-only chassis inventory and a per-switch topology. On top of them: VPCs (a router with its subnets, created and deleted as one object), security groups built from port groups, ACLs and address sets, DHCPv4 and DHCPv6 options, DNS records, load balancers and load balancer groups, policy routing, QoS and meters. Deleting a switch that still has ports, or a VPC whose subnets still carry workloads, is refused, naming what is in the way.
• VMs on OVN: OVN Logical Switch is a network type in the Add and Edit Network Interface dialog, with OVN DHCP as the default address assignment. The logical port is created before the VM is defined and removed with the interface, and the VM's MAC address is recorded on both sides so that OVN's DHCP answers it. Moving a stopped VM to another host maps its OVN interfaces to a logical switch — or another network — on the destination, including one in a different OVN deployment. The host needs the Open vSwitch client (ovs-vsctl); Vapor says so when it is missing.
• OVN activation wizard: Activate OVN on a host without editing configuration by hand, in one of three ways: form a Vapor-native deployment (bootstrap a new clustered database, or join an existing one with a single-use token minted on a central host), join an existing external OVN, or join an existing Kube-OVN cluster. Discovery and preflight checks run first, and a host's existing OVN databases are replaced only after you confirm it. Deactivating releases only what Vapor itself configured, so a Kube-OVN node stays on its network.
• Host configuration from the UI: Host > System > Configuration reads and edits vapor.conf — a form for the common settings and a raw view for the rest — and restarts Vapor. The restart is health-checked: if Vapor does not come back, the previous configuration is restored. Comments and key order survive an edit, and the signing key is never shown or overwritten.
• Memory snapshots of VMs with raw disks: A running VM whose disks are raw files can be snapshotted with its memory and reverted.

Enhancements:

• A UEFI VM's firmware variables, which hold its boot entries, are saved with each backup and put back on restore; a VM restored under a new name gets its own copy instead of sharing the original's. Replication recovery points carry them too, and failover and test failover boot with them.
• Restores show their progress. With Overwrite existing VM, the dialog hides the new-name field and warns that the VM will be stopped and replaced and stays powered off afterwards — emphasised when it is running.
• A running VM reports the operating system its guest agent names, for example "Ubuntu 20.04.5 LTS", so an imported or migrated guest no longer shows no OS.
• A VDDK import that cannot open the source disk reports the reason VDDK logged — a wrong thumbprint, an unreachable port — instead of only "Unknown error".
• The backups of a VM that is no longer defined on the host can still be listed.
• A clone records the UUID of its source, which survives renaming the source.
• The Name field of a running VM is disabled, instead of the rename being refused at save.

Security:

• An image arriving by upload or URL download — including uploads through the storage browser — is refused (422 IMAGE_NOT_SELF_CONTAINED) if it names a backing file or an external data file. Offered as an image, such a file would copy another file on the host, for example another VM's disk, into every VM created from it. Earlier versions accept such images; upgrade to 3.3.0.
• The file name of a storage pool upload must be a plain name. A name containing a path could place the file outside the pool. Earlier versions are affected; upgrade to 3.3.0.

Fixes:

• Restoring a backup brings back the whole VM, and can overwrite it. A restore with Overwrite existing VM failed with domain … already exists, a VM with several disks came back with only one, and a restored VM got 2 GiB of memory and 2 vCPUs whatever the original had. A backup now records the VM's definition, and a restore rebuilds the VM from it — every disk, memory, CPU and networks. Overwriting stops the existing VM, even a running one, and replaces it under the same UUID, so its backups and anything that refers to it still find it. Backups taken before 3.3.0 carry no definition: they restore every disk, with default memory, CPU and network settings.
• Memory snapshots of UEFI VMs work. Every snapshot with memory of a UEFI VM failed, because libvirt does not take internal snapshots of VMs with UEFI firmware. They are now external snapshots with a separate memory file, and can be reverted and deleted.
• Editing a VM no longer leaves it unable to start. Three edits could do it. Any edit dropped the VM's CPU feature flags, so a VM that needs one — such as svm disabled on the qemu64 model — failed its next cold start with Host CPU does not provide required features. Giving a disk a boot order on a VM that boots by device type detached that disk. And saving a VM whose interface sits on a bridge-mode libvirt network turned it into a bridge interface on a device that does not exist (Cannot get interface MTU). CPU features now survive an edit, the disk stays attached, and the interface stays on its network.
• Cloning a stopped VM works with SATA and raw disks. A stopped VM with a SATA disk — common for Windows guests and VMware imports — failed to clone with Found duplicate drive address, and a VM with a raw disk failed with Image is not in qcow2 format, as did creating a template from it and deploying that template. A clone also no longer gains a CD-ROM its source never had, keeps a raw disk raw, and keeps its source's machine type instead of being moved to q35.
• The VM list and the data Cockpit synchronises report UEFI, Secure Boot and TPM. Cockpit recorded every VM as BIOS without TPM; a firmware loader without "OVMF" in its path read as BIOS, and Secure Boot switched off read as on.
• TLS certificates name the addresses clients use. A regenerated certificate listed every address on every interface at that moment, container and VM interfaces included, and could still show a host's old address after it was renumbered. It now names loopback and the host's real interface addresses, and VAPOR_TLS_SANS sets the list outright. The TLS tab says whether the certificate covers the address you connected on. Nothing changes until you regenerate a certificate; regenerating the API certificate changes its fingerprint, so a controller that pins the host must pin it again. If the old address is still assigned to an interface, remove it or set VAPOR_TLS_SANS.
• Creating an OCFS2 storage pool for a cluster with global heartbeat failed at formatting with Unsupported feature(s) found when parsing fs-features string.
• A host is reported as keeping its OCFS2 cluster across a reboot only if its global heartbeat can start: each heartbeat device must be set to come back (iSCSI automatic startup, or listed in /etc/ceph/rbdmap) and o2cb must start after the service that provides it. A host could be reported as persistent and still come back with every OCFS2 mount failing, while one ordered correctly through a service alias was reported as not persistent.
• Replicating a VM with a single disk never completed: its recovery point stayed pending and could not be failed over. A test failover of a UEFI VM also shared the recovered VM's firmware variables, so tearing the test down deleted them.
• Deleting a backup of a VM with several disks left every disk after the first on storage.
• A graceful restart was reported as failed although the guest had rebooted. Power actions sent under other names — shutdown, reboot, suspend, force-off, force-reboot — are accepted instead of refused as unknown.
• VMs created in the wizard had no room to hot-add vCPUs or memory: Max vCPUs and Max Memory always equalled the current values (since 3.1.0). They now default to the host's CPU count and memory, and memory fields default to GiB.
• Creating a NAT or routed network without an IP range returned an error but created the network anyway.
• Removing an interface's address and adding the interface to an OVS bridge could leave the same address on the bridge member and on the bridge's internal port. An address already held by another interface is now refused, and saving an OVS port no longer pins its MTU to whatever it happened to be.
• Licence dates are written with the month spelled out, in the UI's language, so a date such as 10/9/2026 can no longer be read as two different days.

---

Version 3.2.0 (September 2026)

A migrated guest can keep its disks in a folder of its own. A download can be told which certificate authority to trust, so a server with a private certificate needs nothing installed on the host. And hosts in the RHEL family — Rocky, Alma, RHEL 9 — can now create VMs that they used to refuse outright.

New Features:

• A guest's disks in a folder of their own: A disk imported or downloaded into a storage pool can be placed in a directory named after the guest, instead of lying loose at the pool root beside every other migration's. Vapor reports where it stored each file, because a file inside a directory is not a pool volume and no listing would ever show it.
• Tell a download which authority to trust: A download can be given a certificate authority to verify the source against. A server presenting a private certificate is reachable without installing anything into the host's trust store, and verification is still performed — this is not an option to skip it.
• Warm ingest into a subdirectory: The writable target a live migration streams into can sit in a directory under the pool, so a warm migration lands where a cold one does.
• QEMU guest agent: A VM can be created with the guest agent wired up over virtio-serial and cloud-init provisioning applied. Interface names as the guest itself sees them are reported.
• Convert a volume to another format, from the storage view.
• NFS version for storage pools: Pin the NFS version a pool mounts with instead of leaving it to negotiation.
• OCFS2 heartbeat devices are formatted for you, with a size check and an explicit override.
• Multipath management: Configure multipath from the UI, and reload multipathd without a shell on the host.
• Certificate names: The libvirt server certificate's subject alternative names are reported, so a name mismatch can be seen rather than guessed at.

Enhancements:

• A refused login says in the host's own log why it was refused — unknown user, not in the sudo/wheel group, or rejected by PAM — while the answer to the caller stays deliberately vague.
• iSCSI targets reconnect after a reboot: the node.startup preference is written through to iscsiadm instead of living only in Vapor.
• A running VM's interface addresses stop flickering, and an inactive VM keeps stable interface names.

Fixes:

• RHEL-family hosts can create VMs. Two assumptions stood in the way. Vapor named /usr/bin/qemu-system-x86_64 outright, which is the Debian layout and not where RHEL puts it, so creation failed with Cannot check QEMU binary. It also asked for a qxl display, which RHEL 9 and its rebuilds no longer ship, so the domain was refused with does not support video model 'qxl'. Both are now read from what libvirt says the host offers. A host that already worked gets exactly what it got before.
• Turning on UEFI, Secure Boot or TPM for an existing VM no longer forces qxl either, so that edit stops failing on the same hosts.
• Volume operations understand folders: a disk in a subdirectory can be deleted and reports its real capacity, instead of appearing to be missing.
• Multi-disk backups: change-tracking checkpoints are correct per disk, and are no longer left behind.
• A cross-site replication push that failed no longer records a completed recovery point, and a multi-disk replica registers as one recovery point rather than several.
• An explicitly requested CPU topology is applied instead of being silently discarded.
• A VM's disks appear in the sync snapshot, and OVS bridges attach as configured.
• An interface that cannot be given its address says so, instead of leaving a half-applied IP configuration behind.

---

Version 3.1.0 (August 2026)

Vapor hosts can now hand VMs to one another. A stopped VM moves to another host from within Awanio, the move can be called off while it runs, and the destination is checked for room and reachability before anything is copied. Replication and migration traffic can also be given a network path of their own.

New Features:

• Move a VM to another host: Cold migration for a stopped VM. Vapor confirms the destination is reachable and has room before copying, leaves disks that already sit on shared storage where they are, and cleans up after itself if a copy fails.
• Cancel a migration in progress: A migration under way can be called off, and is reported as cancelled rather than failed.
• Rename a VM: A rename carries through everything that referred to the old name — disk paths in the VM's definition, its backup folder and filenames, and the records pointing at them. The VM has to be stopped to be renamed.
• Host service endpoints: Give replication and migration traffic their own interface on the host, separate from management, assigned from the interface view.
• Asynchronous failover: A failover returns straight away and reports its progress, instead of holding the connection open for the whole operation.
• System hosts file: View and edit the host's /etc/hosts from the System tabs.

Enhancements:

• Faster virtual networking: virtio interfaces now use vhost, multiple queues, and larger ring buffers.
• Templates: Creating a template from a VM runs in the background and can be cancelled while it runs.
• A VM's details show the security labels it is running with, and say plainly when the host cannot report them.
• A running Vapor states exactly which build it is, both in --version and in its health endpoint.
• VM names containing spaces or special characters are refused up front rather than accepted and mishandled later.

Fixes:

• A disaster-recovery test built the recovery VM from the live source's definition instead of the replica's, and carried the source's CD-ROM and floppy devices into it.
• Reprotect after a failback could derive the wrong name, and the recovered VM did not keep its original identifier — so a second cycle could lose track of the original.
• An incremental backup that had in fact copied the whole disk was still recorded as incremental.
• A failover's outcome went unrecorded when the caller stopped waiting for it.
• Cloning a VM with an ISO or CD-ROM attached failed without explaining why.
• Nodes added to an o2cb cluster were not registered, and a retried image download did not say why the previous attempt had failed.

---

Version 3.0.2 (August 2026)

Vapor can now serve as a disaster-recovery site. A protected VM replicates to a second site on a schedule, can be brought up there when it is needed, and is then protected again in the opposite direction.

New Features:

• Site-to-site replication: Protect a VM by replicating it to a second site on a schedule you set, keeping recovery points daily, weekly, or monthly.
• Failover: Bring a protected VM up at the recovery site — planned, with a final sync and a clean shutdown of the original, or unplanned when the source site is unreachable. Interfaces are remapped to the recovery site's networks, disks land in the pool you chose, and the guest can take a new address on arrival.
• Test failover: Boot a replica on an isolated network to confirm it comes up, while the original keeps serving.
• Reprotect: After a failover, the recovered VM becomes a protected source in its own right and replication resumes in the opposite direction.
• Changed-block backups: An incremental backup copies only the blocks that changed since the previous one.

Enhancements:

• Every replica is verified against its source before it counts as a recovery point.
• An interrupted transfer resumes where it stopped instead of starting over.
• A backup stops early with a clear message when scratch space is short, and shows its progress while it runs.
• Choose which disks replicate, request a quiesced copy, and pause or resume protection at any time.
• Eject a CD-ROM, resize a volume while the VM is running, and keep each VM's disks in their own folder.

Security:

• The endpoint that wrote raw data into a VM's disk has been removed, and the read path that remains identifies the disk by its own address rather than by a file path supplied in the request. Versions 3.0.0 and 3.0.1 are affected; upgrade to 3.0.2.
• Vapor refuses a disk image that redirects reads to other files on the host.

Fixes:

• An update that fails now undoes itself. Vapor confirms the new version runs and keeps the previous one before switching over. If the new version will not start, the old one is restored and the service comes back on its own — a host is no longer left needing manual recovery.
• A test failover on a VM with several disks pointed only one of them at the replica.
• Retention could not reclaim space from a long chain of incremental recovery points.
• A sync was recorded as successful before the recovery point had actually reached the recovery site.
• Deleting a backup left its change-tracking checkpoint behind, so the space was never returned.
• Memory and CPU readings for a running VM could exceed their real values.

---

Version 3.0.1 (July 2026)

Adds warm migration support — a Vapor host can now be the destination for a live, minimal-downtime migration of a running VM — along with OS package management in the UI and general reliability improvements.

New Features:

• Warm migration target: A Vapor host can now receive a live migration of a running VM. The guest keeps serving during the transfer and pauses only briefly at cut-over. Works together with Condensa and Cockpit to bring running Proxmox VMs into Awanio.
• OS Libraries & Packages Management: Browse and manage the host's OS libraries and packages from the System tabs.

Enhancements:

• Updater: Now tells you when a new major version is available, instead of reporting "up to date".

Fixes:

• A failed login now returns a clear error instead of a server error.
• Security and reliability hardening across the host agent.

---

Version 3.0.0 (July 2026)

A major release that adds NVIDIA vGPU support, a VDDK-based migration data plane for importing VMs from other platforms, far more resilient incremental backups, clustered storage (OCFS2/O2CB) management, and a hardened, fail-closed security posture.

Breaking change — action required

The Vapor agent now fails closed: it will not authenticate without a configured signing secret, and it derives permissions from the authenticated identity. Configure the JWT secret on every host before upgrading.

New Features:

• NVIDIA vGPU (Mediated Devices): Full support for slicing a physical GPU into virtual GPUs — host-side orchestration and API endpoints, a guided NVIDIA vGPU Manager installer with pre-flight checks, a host-level device management view, and awareness of how many instances each profile has free.
• Warm/Cold Migration Data Plane (VDDK): A disk-import engine for bringing VMs in from VMware, including incremental (changed-block/CBT) transfers, a modern nbdkit + VDDK plugin build, plugin auto-detection, and management of installed VDDK builds. Import progress is tracked live.
• Third-Party Library Management: Install and manage VDDK and NVIDIA vGPU components from the System tabs, with resumable (TUS) uploads for large files.
• Guest Agent API: A general QEMU guest-agent interface (raw command and exec), plus endpoints to ensure the agent channel and to remove cloud-init seed files.
• O2CB / OCFS2 Cluster Management: Maintenance mode with persistent boot configuration, a heartbeat/network timeout management API, explicit cluster selection when creating OCFS2 pools, and cluster bootstrapping — all with host-namespace-aware safety checks.

Enhancements:

• Safer migrations: The migration UI now requires acknowledging destructive actions, and the migration store is pruned automatically while always reporting the newest status.
• Better restores: Choose a target storage pool, restore into an independent disk copy, and attach existing disks with clear dependency warnings for incremental/differential chains.
• Storage browser: Rename, move, and track VM attachments for files in the browser.
• VM editing: Custom CPU mode validation, and firmware/machine settings are preserved for running VMs so edits aren't rejected.
• Operations: A deploy-peers build target distributes the binary to peer hosts and restarts the service.

Security:

• Fail-closed authentication with signing-algorithm pinning and permissions derived from the authenticated identity.
• Rate-limiting on login endpoints, trusted proxy-header handling, and SSRF guards on Ansible-driven operations.
• Authorization-coverage re-audit follow-ups across handlers.

Bug Fixes:

• Incremental backups: Deletion and retention no longer destroy incremental chains; silent rebase-delta failures are detected; qemu-img no longer creates the destination image; and interrupted jobs no longer corrupt incremental targets.
• Libvirt performance & stability: Optimized pool listing, periodic connection recycling, request timeouts, event-loop initialization, and resource-leak fixes address prior lag; metric sweeps are throttled via single-flight and caching.
• Fixed a WebSocket metrics-pump goroutine leak on unsubscribe/resubscribe.
• Fixed a duplicate-column failure (migration 21) on databases that never ran migration 20.
• Corrected VM metadata format after metadata updates, and added a default VNC graphics device so restores boot cleanly.
• License validation tolerates an expired control-plane heartbeat lease during the refresh window.
• Sessions no longer time out during long-running background tasks and uploads.
• Fixed Windows BIOS migration and refreshed the v2v tooling.