VMware to Vapor

This guide covers migrating a VMware VM directly into a single KVM/libvirt host managed by Awanio Vapor — no Cockpit in between. Use this path for a single-node target or an edge site. Because the Vapor provider is the host, there is no "target host" to choose — the disk lands on that Vapor host.

It continues from the shared steps in the User Guide — make sure you have enabled CBT (for warm migration) and signed in to Condensa first.

Before you start

• Complete Enable CBT and Sign in to Condensa from the overview.
• Have a reachable Vapor endpoint and a long-lived API token for it. See the Vapor integration guide for how Condensa talks to Vapor and how to mint a token.
• Unlike the CEP path, you do not take a VMware snapshot by hand — for warm migrations Condensa creates and cleans up the snapshots for you.

Add the Vapor provider

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

1. Vendor — choose Awanio Vapor.
2. Name — a display name (e.g. Vapor Edge-01). Add an optional Label to tell apart several Vapor providers, and an optional Description.
3. Under Connection Details:
   • API Endpoint — the base URL of the Vapor API, e.g. https://vapor-host:7770/api/v1.
   • API Token — a long-lived token from Vapor. Create one in Vapor via POST /auth/tokens; it is shown only once on creation.
   • Connection security — three modes, in descending order of trust:
     • Verify certificate — the endpoint must present a certificate signed by a trusted CA. Use this wherever a real certificate is installed.
     • Pin this endpoint — only this server's key is accepted, with no CA and no DNS name required. This is the right choice for a self-signed endpoint or a bare IP address. Condensa shows the fingerprint it sees; compare it against what the server itself reports, then accept it. Because the public key is pinned rather than the certificate, an ordinary renewal does not break the pin.
     • Skip verification — any certificate is accepted, including an attacker's. Throwaway labs only.
4. Click Create Provider.

The new provider appears in the Providers list.

Create the migration

Click the Migrations tab, then click the Create Migration button. The wizard has five steps.

Step 1 — Basic Info and target

1. Enter a Migration Name and an optional Description.
2. Target Provider — choose the Vapor provider you just created. There is no Target Host step on this path — the Vapor provider is the host.
3. Target Storage Pool (optional) — where the migrated disk is written. Leave blank to use the host's default image pool.

Click Next.

Step 2 — Source provider

Select the VMware source provider and its Datacenter, then click Next.

Step 3 — Select VMs

Pick one or more VMs to migrate. Each row shows its power state and, for VMware, whether CBT is on — a running VM with CBT off (and no snapshot) can't be migrated warm. Click Next.

Step 4 — Mapping

These settings apply to the whole migration, and each VM's card below can be given its own answer instead.

1. Name Prefix (optional) — prepended to every migrated VM's name. Rename a single VM on its card.
2. Give the migrated VMs new MAC addresses — leave off to keep each interface's source MAC, so the guest's own network configuration still applies. Turn it on for a copy that has to run alongside a still-running original on the same layer 2.
3. Power on the VM after migration — leave it unchecked to keep the migrated VM powered off until you start it yourself, which avoids an identity conflict with a source that is still running.
4. Keep the final snapshot on the source VM — VMware sources only. Leaves a warm migration's last checkpoint on the source as a restore point; it grows a delta disk for as long as it exists, so delete it when you no longer need it.
5. Manual cutover — a warm migration copies the disk, then waits for you to shut the guest down from inside the OS at a moment you choose, instead of powering the source off itself. Turn it on for a guest that needs its own shutdown sequence, such as a database. Cold migrations are unaffected: the guest is already off. Each VM's card below carries the same power, cutover and keep-snapshot switches, so one guest can be left powered off, given a manual cutover, or be the only one whose final snapshot is kept, without changing the rest.

Networks are mapped on each VM's card. Every interface the source VM had is listed there by its source network; choose the target network it lands on. An interface left unmapped is not created, and the card says so — leaving one out is how you keep a copy off a network where it would clash with the still-running source. When the selected VMs share source networks, Per-network mapping above the cards sends a source network to the same place on every VM at once. To give a VM an interface its source did not have, use Attach an interface on on its card.

Warm or cold is not a choice here: a running guest migrates warm and a powered-off guest migrates cold, decided per VM. Warm needs CBT enabled on the source (see the overview); a running guest without it cannot be selected.

Step 5 — Review

Review the migration. The summary shows the target Vapor host, storage pool, network, and every per-VM change. Go Previous to adjust one. If it is OK, click Create Migration.

The migration appears in the list with a Preparing status.

Start and monitor the migration

1. Click the action menu (three dots on the right of the row), then select Start Migration.
2. The status changes to Running and progress increases toward 100%. For a warm migration you'll see the phase move from the initial data copy to the final cut-over.
3. On completion the status changes to Success. Click the migration name to see per-disk detail and the log.

The migration list, status badges, and detail view are identical in layout to the CEP guide — only the Target Provider column reflects your Vapor provider.

Verify on Vapor

Open the Vapor host's dashboard, go to Virtualization, and confirm the migrated VM is present and (if you chose to power it on) running. Attach or adjust the NIC there if you left the network as None during migration.

Screenshots for the running/verify steps

End-to-end warm screenshots (Running → Success → the VM on the Vapor host) are captured against a Vapor build that includes the warm-ingest data plane. They will be added once that build is deployed. The wizard and provider screenshots above are from the live UI.