Proxmox VE as a source

This guide covers migrating guests out of Proxmox VE into a KVM/libvirt target — either a single host managed by Awanio Vapor or a host fleet managed by Awanio Cockpit. The target side of the wizard is exactly the one described in VMware to Vapor and VMware to Cockpit; everything that differs is on the source side and is described here.

The Awanio CEP (KubeVirt) target is not available for a Proxmox source. Choose a Vapor or Cockpit target.

Before you start

• Sign in to Condensa from the overview.
• Add the target provider first — Vapor or Cockpit.
• Have the Proxmox API reachable from Condensa (port 8006 by default) and SSH to every PVE node that holds a guest you intend to migrate.
• There is no CBT step and no manual snapshot. Proxmox needs nothing enabled on the source, and Condensa decides warm or cold from the guest's power state.

Why Condensa needs SSH to the node

Proxmox VE exposes no REST endpoint that streams the content of a volume, so both data planes run on the node itself over SSH:

• Cold — Condensa resolves the volume with pvesm path and reads it directly.
• Warm — Condensa drives the running guest's own QEMU monitor to mirror the disk live.

The API credentials (root@pam and its password) are used for inventory only. Disk data never travels over the Proxmox web API.

Add the Proxmox provider

Click the Provider tab, then Add Provider. In the form:

1. Vendor — choose Proxmox VE. The port switches to 8006 automatically.

2. Name — a display name (e.g. Proxmox Jakarta). Add an optional Label to tell apart several Proxmox providers, and an optional Description.

3. Under Connection Details:

   • Host — the node or cluster address, e.g. proxmox.example.com.
   • Port — 8006 unless the host changed it.
   • Username — a PVE API user, e.g. root@pam.
   • Password — that user's password.
   • Allow insecure connection — tick this for a self-signed PVE certificate. It is also required for the SSH data plane today, because the host key is not pinned yet.

4. SSH Port — 22 unless the node's sshd listens elsewhere.

5. SSH Key for cold migration — click Generate SSH key. Condensa creates the keypair and keeps the private half encrypted; copy the public key it shows and install it on the node, as root:

   mkdir -p ~/.ssh && echo 'PASTE_THE_PUBLIC_KEY_HERE' >> ~/.ssh/authorized_keys

6. Click Create Provider, then Test Connection on the new card.

The provider appears in the Providers list once the connection test passes.

Debian refuses root passwords over SSH

Debian — and therefore Proxmox VE — ships sshd with PermitRootLogin prohibit-password. The correct API password is still refused for SSH, so the generated key is not optional. If Test Connection reports API success but a migration fails to reach the node, the public key is missing from ~/.ssh/authorized_keys.

Warm or cold is decided for you

Unlike the VMware paths, you do not choose the migration mode. Condensa reads each guest's power state when you create the migration:

Guest state at creation	Mode	What happens
Running	Warm	The disk is mirrored live while the guest keeps serving. At cutover the guest pauses, the last changes flush, and the target VM is created.
Stopped	Cold	The volume is read from the node and written to the target. No downtime to schedule — the guest is already off.

Each guest shows its mode as a Warm or Cold pill in step 3 and again in the review step.

What a warm cutover costs

The guest keeps running for the whole copy. Only the cutover pauses it, and only for as long as the final flush takes — measured at a quarter of a second on the lab.

If the guest runs qemu-guest-agent, Condensa freezes its filesystems for that instant, so the captured image is application-consistent. Without the agent the cutover is crash-consistent: the guest still boots and its filesystems and databases recover on start, exactly as they would after a hard pause. The migration log says which of the two happened.

The source guest is left paused, not deleted

After a successful cutover the source guest stays on Proxmox, paused. Nothing is removed. Verify the migrated VM first; to roll back, resume the source guest and thaw its filesystems:

qm resume VMID && qm agent VMID fsfreeze-thaw

Delete the source guest yourself once you are satisfied.

Create the migration

Click the Migrations tab, then Create Migration.

Step 1 — Basic info and target

Fill in the Migration Name, choose the Target Provider, and — for a Cockpit target — the Target Host. Set the Target Storage Pool and the default Target Network. These fields behave exactly as in the VMware guides.

Step 2 — Source provider

Select the Proxmox VE provider. There is no datacenter to pick — Condensa browses the whole cluster.

Step 3 — Select guests and map networks

Pick one or more guests. Each row shows its power state and the Warm or Cold pill it will migrate with.

Below the table, if the selected guests sit on more than one source bridge, a network mapping block appears: one dropdown per source bridge (vmbr0, vmbr1, …), each choosing the target network its interfaces land on.

• Leave a bridge at its default and its interfaces join the step-1 target network.
• Map two bridges to two different target networks to keep the separation the guest expects.
• Map a bridge to None to leave those interfaces off the target entirely.

Step 4 — Review

Check the target, the pool, the networks, and the per-guest mode, then click Create Migration.

What arrives on the target

Condensa reproduces the parts of a guest's identity that its own configuration depends on:

• Every network interface, not just the first — each with its source MAC address kept, so netplan match: macaddress: rules and RHEL HWADDR files still bind.
• The adapter model where the target can offer it (virtio stays virtio), because the model decides the interface's name inside the guest — ens18 against enp1s0. A model with no KVM equivalent falls back to e1000, and the log says so.
• The disk bus family the source used, so a guest whose initramfs only carries the virtio-scsi driver still finds its root device.
• Firmware and disk order, so the guest boots the disk it booted before.

The migration log lists all of this for each guest — read it if the migrated VM's networking looks unfamiliar.

Start and monitor the migration

1. Open the action menu (three dots on the right of the row) and select Start Migration.
2. The status changes to Running. A warm migration shows the mirror progressing and then a Cutover phase; a cold migration shows the transfer.
3. On completion the status becomes Success. Click the migration name for per-disk detail and the log.

A failed migration can be restarted from the same action menu with Retry — it starts a fresh attempt and leaves the earlier failure in the history.

Disk space on Condensa

A cold migration normally needs none: whatever the volume's format — qcow2 on file storage, or raw on LVM-thin, ZFS, or Ceph RBD — it is converted on the node and lands only on the target. Blocks that hold nothing never cross the wire, so a mostly-empty volume transfers quickly and arrives thin.

Scratch space is used only by the fallback path, when the node cannot reach the target or cannot read a volume: the disk is then staged on Condensa (roughly the guest's used space) before the target fetches it. Condensa checks free space before it starts a staged migration and refuses one that would not fit, naming the shortfall. Staged migrations also run one at a time, so several large guests queue instead of filling the disk together. Warm migrations never stage.

Cold migrations stay inside your network

A cold migration is converted on the Proxmox node and written straight into the target's storage, over the same authenticated, short-lived channel a warm migration uses. The disk never passes through Condensa, and Condensa needs no public address. What the node must be able to reach is the target host's migration port range — the same rule warm migration already has (see below).

If that direction is blocked by a firewall, the migration does not fail: Condensa says so at the start, naming the address, and continues on a fallback path that it carries itself. Only that fallback can involve the target downloading from CONDENSA_PUBLIC_URL, with the same address rules as before.

Warm migration to a Cockpit fleet

A warm migration is the source dialling the target, which makes the target's address matter in a way nothing else does. Cockpit registers each host by its management address, and a Proxmox node on another network cannot reach that address.

Set CONDENSA_TARGET_WARM_ADDRESS on the Condensa server to the address the source should dial:

CONDENSA_TARGET_WARM_ADDRESS=203.0.113.10

For a fleet whose hosts need different addresses, list them by host name or id — a pair always wins over a bare address, so you only name the exceptions:

CONDENSA_TARGET_WARM_ADDRESS=host-a=203.0.113.10,host-b=203.0.113.11

Leave it unset when the source and the target share a network; the host address Cockpit already knows is then correct. A cold migration dials the same address, so this one setting covers both methods.

Open the migration port range toward the target

The target opens its disk intake on a port from a configurable range. On Vapor 3.0.2 and later, set the range under Host → System → Migration (on each host of a fleet) 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 must permit all of it in that direction. Each export lives for one migration, under a random name. Cold migrations use this same channel, so one rule covers both.

The transfer is encrypted and short-lived

The live disk stream is protected by mutual TLS. Vapor issues the certificates itself and Condensa installs the source's half on the PVE node over SSH for the length of the migration, then removes it. There is nothing to generate or distribute by hand, and the export exists only while that one migration runs.

Verify on the target

Open the target host's dashboard, go to Virtualization, and confirm the migrated VM is present and running. Check inside the guest that every interface came up on the network you mapped it to before you delete the source guest on Proxmox.

For credit-based licensing and how migrations consume credits, see Licensing.