User Guide
This guide explains how to migrate virtual machines with Condensa from Awanio.
Condensa moves VMs out of VMware vSphere/ESXi, out of Proxmox VE, or out of another Awanio CEP site, and into an Awanio target. Depending on where the workloads come from and where you want them to run, Condensa supports the migration paths below. Signing in to Condensa is the same for all of them; the source provider and the target provider decide the rest.
Choose your migration path
| Path | Target | Best for | Guide |
|---|---|---|---|
| VMware → CEP | Awanio CEP (KubeVirt cluster) | Teams standardizing on the Awanio container platform / Kubernetes | VMware to CEP |
| VMware → Cockpit | A KVM/libvirt host fleet managed by Awanio Cockpit | Multi-host virtualization without Kubernetes | VMware to Cockpit |
| VMware → Vapor | A single KVM/libvirt host managed directly by Awanio Vapor | A single-node target or an edge site (no Cockpit) | VMware to Vapor |
| Proxmox → Vapor | A single KVM/libvirt host managed directly by Awanio Vapor | Leaving Proxmox VE for a single-node target | Proxmox VE as a source |
| Proxmox → Cockpit | A KVM/libvirt host fleet managed by Awanio Cockpit | Leaving Proxmox VE for a managed fleet | Proxmox VE as a source |
| CEP → CEP | Another Awanio CEP (KubeVirt cluster) | Moving guests between Awanio sites — consolidation, a move to your own cluster, or leaving a provider | Awanio CEP as a source |
Read the shared sections below first, then follow the guide for your chosen path. A Proxmox source needs no preparation on the source side — skip straight to Proxmox VE as a source.
What must reach what
Who carries the disk bytes differs by path, and that decides which firewall rule you actually need. Find your row before you plan the network.
| Source | Target | Method | What carries the disk | What must reach what |
|---|---|---|---|---|
| VMware | CEP | Warm or cold | CDI, inside the cluster | Cluster nodes → vCenter/ESXi (443, 902). Condensa is not in the data path. |
| VMware | Vapor or Cockpit | Warm, and cold where VDDK is installed | The target host pulls from ESXi over VDDK | Each Vapor host → vCenter/ESXi (443, 902), with the VDDK toolchain installed on that host. Condensa is not in the data path. |
| VMware | Vapor or Cockpit | Cold, where VDDK is not installed | Condensa stages the disk; the target downloads it over HTTP | Target host → Condensa at CONDENSA_PUBLIC_URL — a public address, see below |
| Proxmox | Vapor or Cockpit | Cold | The PVE node converts the disk straight into the target's storage | Condensa → PVE node (SSH), and PVE node → target host on the migration port range, see below |
| Proxmox | Vapor or Cockpit | Warm | The guest's own QEMU mirrors into a writable export on the target | Condensa → PVE node (SSH), and PVE node → target host on the migration port range, see below |
| Proxmox | CEP | — | Not supported | Choose a Vapor or Cockpit target |
| CEP | CEP | Cold only | The target cluster's importer fetches the source site's export | Target cluster nodes → source site API (443), plus Condensa → both site APIs. Condensa is not in the data path and needs no public address. |
| CEP | Vapor or Cockpit | — | Not supported | Choose a CEP target |
The target must reach Condensa at a public address
Every path in the table that downloads over HTTP hits a guard on the target host: Vapor refuses any download URL that resolves to a loopback, private (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16), or link-local address, and there is no setting to turn it off. It exists because Vapor runs as root and fetches the URL for you, so an operator-supplied URL must not be able to reach inside the host's own network.
Condensa applies the same rule when the migration starts, so a CONDENSA_PUBLIC_URL pointing at a private address is refused in a sentence rather than after the whole disk has been exported. The paths that avoid the download entirely are VDDK (VMware) and every Proxmox path — cold converts on the node, warm mirrors from the guest, and neither puts Condensa in the data path. A Proxmox migration meets this rule only when its fallback runs (the node cannot reach the target), and the log says so first.
If your target is known to accept a private address, set CONDENSA_ALLOW_PRIVATE_STREAM_URL=1 to waive Condensa's check. It waives ours only: the target still decides.
The migration port range
The writable export a Proxmox migration writes into — warm mirror and cold conversion alike — is opened on a port from a configurable range. On Vapor 3.0.2 and later, pin it under Host → System → Migration and permit just that range from the PVE node to the target host. When no range is set, the operating system picks from the ephemeral range (32768–60999 by default on Linux) and the firewall has to permit all of it. The export itself is short-lived: one migration, a random name, and mutual TLS.
Condensa asks the node whether it can reach the port before the guest is touched, so a firewall that permits a port rather than the range is reported as that, and not as a connection refused against an address you have never seen.
Conditions that add a requirement
| If | Then |
|---|---|
| The target host Cockpit knows by a management address the source cannot reach | Set CONDENSA_TARGET_WARM_ADDRESS on Condensa to the address the source should dial — see Proxmox VE as a source |
| The selected guests sit on more than one source network | A mapping block appears in wizard step 3. Bridges you leave unmapped all land on the one default target network — the guest keeps its interfaces but loses their separation |
A source NIC uses a model the target cannot offer (e.g. vmxnet3) | It arrives as e1000, which may rename the interface inside the guest (ens18 against enp1s0) and break name-keyed configuration. MAC-keyed configuration is unaffected |
| A Proxmox cold migration falls back to staging (the node cannot reach the target, or cannot read the volume) | Condensa needs scratch space of roughly the guest's used space, and runs one such migration at a time. On the normal node-to-target path, no format needs any |
A running guest has no qemu-guest-agent | The warm cutover is crash-consistent: the guest boots and recovers as it would after a hard pause, rather than being quiesced first |
| The migration stages through Condensa | qemu-img must be installed on the Condensa host (sudo apt install qemu-utils) |
Migration Method
There are 2 migration methods in Condensa:
- Warm Migration: Migration of running VMs with minimal downtime.
- Cold Migration: Migration of a powered-off VM, or by uploading files exported from the source (OVA, VHD, VHDX).
Warm and cold are available on every path. From a VMware source, warm migration needs Changed Block Tracking (CBT) enabled first, described next. From a Proxmox VE source nothing has to be enabled, and Condensa picks warm or cold from the guest's power state.
Warm migration prerequisite: enable CBT (VMware source)
This step is shared by all three VMware paths and does not apply to a Proxmox source. Any warm migration from VMware reads only the changed blocks between passes, which requires CBT to be enabled on the source VM before the migration starts.
Snapshots: For the CEP path you must also take a snapshot manually after enabling CBT — this is covered in the VMware to CEP guide. For the Cockpit and Vapor paths, Condensa creates and cleans up the snapshots for you, so you only need to enable CBT.
Important: CBT must be enabled BEFORE the migration runs.
Log in to your VMware environment. The example below is for ESXi.
Power off the VM (if it is running): Right-click the VM → Power → Shut Down Guest OS
Enable CBT:
- Click Edit
Click the VM Options tab
Expand Advanced
Click Edit Configuration
Add the following parameter: ctkEnabled = true, then click OK to save
Power on the VM
Sign in to Condensa
The steps from here are the same until you add a provider. Open the configured Condensa page. The Condensa login page looks like this:
Enter the Awanio administrator user's username and password, then click SIGN IN.
After that, the Migrations page will appear.
Next: follow your path
Continue with the guide that matches your target:
- VMware to CEP — migrate into the Awanio CEP (KubeVirt) cluster.
- VMware to Cockpit — migrate into a KVM/libvirt host fleet managed by Awanio Cockpit.
- VMware to Vapor — migrate directly into a single KVM/libvirt host managed by Awanio Vapor.
- Proxmox VE as a source — migrate guests out of Proxmox VE into a Vapor host or a Cockpit fleet.
- Awanio CEP as a source — migrate guests from one Awanio CEP site into another.
For credit-based licensing and how migrations consume credits, see Licensing.