Condensa Release Notes

This log tracks updates, new features, and bug fixes for Condensa.

---

Version 1.6.2 (August 2026)

A warm migration no longer removes snapshots it did not create. Until now it removed every snapshot on the source VM, twice per run — and the first of those removals happened before any data was copied. An operator who took a snapshot as a safety net before migrating lost it at the first step, and only then did the copying begin.

• Only checkpoints named condensa-warm-* are removed. Anything else on the VM is left exactly as it was.
• The migration log says how many of its own checkpoints it cleared, and states that other snapshots were untouched, so the boundary is visible rather than assumed.
• Your own snapshot survives whether the migration succeeds or fails.

If you have been keeping a pre-migration snapshot and found it missing afterwards, this is why. There is nothing to configure — the previous behaviour was not something to opt out of.

Change tracking is checked on every disk before any data moves. vSphere records change tracking twice: once on the VM and once on each disk, and only the per-disk setting decides whether a disk can report its changed blocks. Condensa read only the VM-level one, so a warm migration could report change tracking as ready, transfer for several minutes, and then fail on a disk that was never able to supply it.

• The check now runs in the first seconds and names the disk by its bus address — scsi0:0, not an internal device number.
• When a disk is not ready, the message says what usually fixes it: power the VM off and on once so the setting takes effect, or migrate that VM cold.
• Warm migrations that were already working are unaffected.

The update banner reloads the page itself. Installing an update from the dashboard banner used to ask you to reload after a few seconds. It now waits for the restart and reloads on its own, as the About dialog already did, and says so plainly if the restart takes longer than expected.

---

Version 1.6.1 (August 2026)

A warm migration now reports the consistency it actually achieved. Asking vSphere for a quiesced snapshot and getting no error back is not the same as the snapshot being quiesced: the request succeeds on a guest where VMware Tools is not running, and the snapshot is crash-consistent anyway. Condensa now reads the flag back from the hypervisor and reports what it finds.

• A copy is called application-consistent only when vSphere says the snapshot was quiesced.
• Crash-consistent is now stated plainly instead of passing in silence, and the log names what would change it — VMware Tools running in the guest. Silence used to read as the better answer.
• When the flag cannot be read at all, the log says so rather than choosing a side.

This matters most for databases and anything else that expects a consistent point in time. A crash-consistent copy is often perfectly usable; being told it was application-consistent when it was not is what leaves an administrator surprised at the worst moment.

The update status no longer promises what the host cannot deliver. An installation without the updater component now says so when you check for updates, instead of accepting the request and waiting for a restart that nothing will perform.

---

Version 1.6.0 (August 2026)

A provider can now be pinned. Self-signed certificates on bare IP addresses are an ordinary posture for on-prem and air-gapped installs, not only a lab shortcut — and until now the only way to reach one was to accept every certificate, which accepts an attacker's too. Pinning gives the setting that was missing between those two: no certificate authority required, and nothing trusted on faith.

Installations on 1.3.1–1.5.1 update by hand once

On versions 1.3.1 through 1.5.1 the Install update button does not complete: the dialog keeps waiting and reports "the restart is taking longer than expected", or a file-system error. Installations on 1.3.0 and earlier are not affected.

Update those installations once by hand. Stop the service, replace the binary with the one from this release, and start it again:

sudo systemctl stop condensa
curl -fLo /tmp/condensa.tar.gz <the download URL from the enterprise portal>
sudo tar -xzf /tmp/condensa.tar.gz -C /usr/local/bin condensa
sudo systemctl start condensa

Nothing is reconfigured: providers, credentials, migration history and both secrets are untouched. From 1.6.0 the button works again, and later releases install themselves. Full steps in Updating.

New

• Three levels of connection security, shown together. Every provider form replaces its lone "allow insecure connection" checkbox with a choice between verifying against a certificate authority, pinning this endpoint, and skipping verification. They are listed side by side because the decision is a comparison — a single checkbox made skipping verification look like the self-signed option, which is exactly the belief that leaves a connection unprotected.
• The fingerprint is shown before you accept it. Selecting Pin this endpoint reads what the server is presenting and displays its fingerprint, subject, issuer, validity and names, so the decision is made on what is actually there. Compare it against what the server itself reports before accepting — reading a fingerprint only from the connection you are about to pin proves nothing if that connection is already being intercepted.
• A renewal does not break a pin. Condensa pins the server's public key rather than its certificate, so a reissue — new serial, new expiry, another address in the list — keeps the same identity. Only a genuinely new key raises a mismatch, and the message then shows both fingerprints side by side so a human can tell a reinstalled server from an impostor.
• Proxmox SSH host keys are pinned separately. Disk data is read on the node over SSH, never through the Proxmox API, so the API's certificate says nothing about that connection. The Proxmox form has its own SSH host key control, with the ssh-keygen -lf command for confirming the fingerprint on the node itself.

Fixed

• The staging space check estimated from the size a volume claims rather than what it holds, so a 40 GiB disk with under a gigabyte in it was billed 80 GiB and refused. Measured on a real guest, the estimate falls from 82.0 GiB to 3.9 GiB.
• A transfer that died reported nothing an operator could act on. The failure now carries the reason the target host gave, instead of a migration that simply stopped.
• A staged Proxmox disk was named twice in the migration log.
• The appliance now keeps its key when it reissues its own certificate. Renewing used to change the appliance's identity, which is precisely what pinning cannot tolerate.
• The two remaining pickers in the migration wizard — target organization and target project — behaved differently from every other field: no typing to filter, no keyboard navigation. They now match the rest of the form.

Upgrading

• Existing providers are unchanged. A provider that allowed insecure connections still does; nothing starts refusing a connection it accepted before.
• Pinning is opt-in per provider, and can be turned off again by clearing the pin.
• On Proxmox, migrating over SSH still requires Skip verification until you pin the node's SSH host key. Pin it, and that requirement goes away.

---

Version 1.5.1 (August 2026)

Installations now know where to find their own updates.

Fixed

• An installation that had no update source configured for it reported that automatic update checks were disabled, and named an environment variable to whoever opened the About dialog. That was most installations rather than an unusual few: the setting was written only when creating a new installation, so a site upgraded in place had never received it, and neither had a server started by hand. The release feed now travels in the binary, so it is found without anything having to be configured — and the dialog reports checks as off only when someone has deliberately turned them off.

Upgrading

• CONDENSA_UPDATE_URL still takes precedence where it is set, and setting it to an empty value still turns update checks off. A site that must not reach the internet should confirm that value is blank before upgrading: an installation that was quiet only because nothing was configured will begin checking for releases once it is on 1.5.1.

---

Version 1.5.0 (August 2026)

Awanio CEP joins VMware and Proxmox VE as a migration source. Guests move from one Awanio CEP site into another — consolidating sites, moving onto your own cluster, or leaving a provider. The source site needs no changes at all: the endpoints it already has are enough, which is what makes this usable against a platform you do not administer. Start with Awanio CEP as a source.

New

• CEP to CEP migration, cold. The source site publishes a guest's disks and the target cluster's own importer fetches them directly. Condensa orchestrates but never carries a byte, so it needs no public address for this path. A running guest is shut down first and left shut down; the migrated copy is what you start on the target.
• The export window is sized from the work, and closed when the work is done. Condensa asks for a lifetime derived from the total disk size rather than a flat number, refuses a guest too large to finish inside it — before anything is stopped — and closes the export when the migration ends, revoking its download token instead of leaving it live until the window expires.
• Real progress, and a transfer that survives an interruption. Disks are fetched in a form that reports its size, so the bar counts a true percentage instead of sitting at zero, and an interrupted transfer resumes from where it stopped rather than starting the disk again.

Fixed

• A migration's progress was recomputed only when it finished, so the bar showed 0% for the whole transfer and then jumped to success. It now updates on every poll, in the migration list and in the detail view alike.
• Where a transfer genuinely cannot report a total, the bar now says size unknown and sweeps, instead of claiming a misleading 0%.
• Guests are listed under the name the site shows for them. Listing by hostname made a migrated copy appear under its original's name — two identical rows an operator could only tell apart by power state.
• Guest inventory from a CEP site now pages through the whole site rather than stopping at the first ten, sums every volume rather than the boot disk alone, reads addresses in each of the shapes a site reports them, and falls back to the catalogue when a guest records no OS variant.

Supported migration paths

Source	Target	Cold	Warm
VMware vSphere / ESXi	Awanio CEP	✓	✓ ¹
VMware vSphere / ESXi	Awanio Vapor (single host)	✓	✓ ²
VMware vSphere / ESXi	Awanio Cockpit (fleet)	✓	✓ ²
Proxmox VE	Awanio Vapor (single host)	✓	✓
Proxmox VE	Awanio Cockpit (fleet)	✓	✓
Proxmox VE	Awanio CEP	—	—
Awanio CEP	Awanio CEP	✓	— ³
Awanio CEP	Awanio Vapor or Cockpit	—	—

¹ The source VM needs changed-block tracking (CBT) enabled and an existing snapshot. ² Needs the VDDK toolchain installed on the target host; VDDK also gives cold migrations a faster direct path. ³ KubeVirt publishes a guest's disks only while it is stopped, and offers no changed-block tracking, so there is no warm variant of this path.

Before you upgrade

• A CEP target must run a platform build that accepts migration disks. On an older build the migration stops at the first disk with a message naming the endpoint — upgrade the target, not the source.
• A CEP source needs nothing: no agent, no configuration, no restart. Against an older source the export simply expires on its own instead of being closed early, and the log says so.
• The target cluster's nodes must be able to reach the source site's API — Condensa reaching both sites is not enough, because the nodes fetch the disk themselves.
• Nothing changes for VMware or Proxmox migrations.

---

Version 1.4.1 (August 2026)

Proxmox migrations now run entirely inside a private network. A cold migration is converted on the Proxmox node itself and written straight into the target's storage, over the same authenticated, short-lived channel a warm migration already uses. Condensa orchestrates but no longer carries the disk — and no longer needs a public address for Proxmox sources at all.

New

• Cold migrations go node-to-target, whatever the volume format. qcow2 and raw volumes alike are converted on the node and land only on the target — no scratch space on Condensa, and blocks that hold nothing never cross the wire, so a mostly-empty volume transfers quickly and arrives thin. Works the same into a single Vapor host and into a Cockpit fleet.
• The migration port range can be pinned on the target. On Vapor 3.0.2, set it under Host → System → Migration; the firewall rule between a Proxmox node and the target host becomes one small range instead of the whole ephemeral range. One rule now covers warm and cold, because both use the same channel.
• A blocked network path is a detour, not a failure. Before any data moves, the node is asked whether it can reach the target's port. If it cannot, the log says so — naming the address and the likely cause — and the migration continues on a fallback path carried by Condensa instead. Only that fallback uses CONDENSA_PUBLIC_URL.

Supported migration paths

Source	Target	Cold	Warm
VMware vSphere / ESXi	Awanio CEP	✓	✓ ¹
VMware vSphere / ESXi	Awanio Vapor (single host)	✓	✓ ²
VMware vSphere / ESXi	Awanio Cockpit (fleet)	✓	✓ ²
Proxmox VE	Awanio Vapor (single host)	✓	✓
Proxmox VE	Awanio Cockpit (fleet)	✓	✓
Proxmox VE	Awanio CEP	—	—

¹ The source VM needs changed-block tracking (CBT) enabled and an existing snapshot. ² Needs the VDDK toolchain installed on the target host; VDDK also gives cold migrations a faster direct path.

Before you upgrade

• Proxmox migrations need Awanio Vapor 3.0.2 or later on the target host, and Awanio Cockpit 3.0.1 or later in front of a fleet. Upgrade Vapor from its own update page before migrating.
• CONDENSA_PUBLIC_URL is no longer required for Proxmox sources. It is still used by VMware cold migrations without VDDK, and by the Proxmox fallback path described above.
• Nothing changes for VMware migrations.

---

Version 1.4.0 (August 2026)

Proxmox VE joins VMware as a migration source. Guests move out of Proxmox VE into a single host managed by Awanio Vapor, or into a fleet managed by Awanio Cockpit. Start with Proxmox VE as a source.

New

• Migrate from Proxmox VE, warm or cold. You do not choose the mode: a running guest is mirrored live and cut over with a pause measured in fractions of a second, a powered-off guest is copied directly. Nothing has to be enabled on the Proxmox side — no changed-block tracking, no snapshot taken by hand. After a successful cutover the source guest is left paused rather than deleted, so you can verify the new VM before letting go of the old one.
• Every network interface arrives, not just the first. A multi-homed guest keeps all of its interfaces, each with the MAC address it had on the source, and its adapter model wherever the target can offer it — so configuration inside the guest that binds by MAC or by interface name keeps working.
• Send each source network somewhere different. When the guests you selected sit on more than one source bridge, the wizard asks which target network each bridge becomes. Map two apart to keep the separation the guest expects, or map one to nothing to leave those interfaces off the new VM.
• Retry a failed migration in place. Restart it from the row's action menu; the earlier attempt stays in the history.
• Live disk streams are encrypted, with nothing to set up. A warm migration to a Cockpit fleet is protected by mutual TLS. The target issues the certificates itself, Condensa places the source's half on the Proxmox node for the length of the migration and removes it afterwards.

Improvements

• A cold migration of a qcow2 volume needs no scratch space at all — it streams from the Proxmox node to the target as it is read. Volumes stored as raw (LVM-thin, ZFS, Ceph RBD) still pass through Condensa, and those are now checked before they start: a migration that would not fit is refused up front naming the shortfall, and only one runs at a time so several large guests queue instead of filling the disk together.
• Warm migration to a target on another network. Set CONDENSA_TARGET_WARM_ADDRESS when the address your management network knows a target host by is not the address the source can reach. See Warm migration to a Cockpit fleet.
• Problems are reported before the work, not after it. If the target would refuse to download from this Condensa, or the Proxmox node cannot reach the target's disk-stream port, the migration says so at the start — naming the address and what to change — instead of after an hour of copying. See What must reach what.
• A warm cutover is application-consistent where it can be. With qemu-guest-agent running in the guest, its filesystems are quiesced for the instant of the cutover; without it the cutover is crash-consistent and the log says which of the two happened.

Bug fixes

• A finished migration shows when it finished. A successful migration displayed "Completed at: In Progress" beside its green badge, and a cancelled one never recorded an end time at all.
• A long transfer is no longer mistaken for a stalled one. A large disk that was copying perfectly well could be failed minutes before it completed.
• A warm migration gives the source guest its resources back. A failed or cancelled warm migration used to leave a block device registered inside the running source guest, which then blocked every later attempt on that same disk — and only restarting the guest cleared it, the very thing warm migration exists to avoid.
• The migrated VM keeps the disk bus its guest expects, so a guest whose boot image carries only one storage driver still finds its root disk.
• The migrations list names the real source. Every migration was labelled as coming from VMware regardless of where it actually came from.

Before you upgrade

• Warm migration into a Cockpit fleet needs Awanio Vapor 3.0.1 or later and Awanio Cockpit 3.0.1 or later on the target side.
• Check What must reach what before planning firewall rules: which machine carries the disk differs by source, target, and method, and that decides the rule you need.
• Nothing in this release changes an existing deployment's behaviour. CONDENSA_TARGET_WARM_ADDRESS is optional and defaults to what Condensa did before.

---

Version 1.3.2 (July 2026)

A maintenance release with no change to how migrations run: it corrects the publishing flow used to deliver Condensa updates.

---

Version 1.3.1 (July 2026)

A reliability release for VMware migrations of large, multi-disk, and long-running VMs.

Bug Fixes:

• Multi-disk BIOS VMs boot without a manual fix: A migrated VM with several disks (legacy/BIOS boot) now boots straight away — the operating-system disk is placed first automatically, so you no longer have to correct the boot order by hand after the migration.
• Long migrations stay connected: A migration that runs for a long time — large disks, or a warm transfer — no longer fails near the end with a "session is not authenticated" error. The connection to VMware is kept alive and re-established as needed, so the final cut-over completes reliably. (Cold migrations were never affected.)