WARNING

This page has not been translated yet and is shown in English. A localized version is coming soon.

Condensa Release Notes

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

---

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.)