Awanio CEP as a source

This guide covers migrating guests out of one Awanio CEP site into another — from a cluster running the Awanio platform to a different cluster running it too. The target side of the wizard is the one described in VMware to CEP; everything that differs is on the source side and is described here.

Vapor and Cockpit targets are not available for a CEP source. Choose a CEP target.

Before you start

• Sign in to Condensa from the overview.
• Have a service account on each site — one on the source, one on the target — and its access key and secret.
• The target site must run a platform build that accepts migration disks (see What each site needs). The source site needs nothing new.
• Plan for downtime on every guest you migrate: this path is cold only.

Cold only, and why

A site serves a guest's disks through a KubeVirt VirtualMachineExport, and KubeVirt publishes one only while the guest is stopped. There is no changed-block tracking to fall back on, so there is no warm variant of this path.

Condensa says so before you commit: step 3 of the wizard carries the notice, and every guest shows a Cold pill.

Guest state when the migration starts	What happens
Stopped	Its disks are exported and copied straight away.
Running	Condensa shuts it down first, waits for it to stop, then exports. It is left shut down afterwards.

The migrated copy is what you start on the target. The source guest stays where it is, stopped — nothing is deleted, so rolling back is starting it again.

A running guest is shut down without a second prompt

Selecting a running guest is the decision. Condensa gives it up to five minutes to stop cleanly and reports a guest that will not; it never force-kills one. Shut down anything with services to flush yourself, at a time you choose.

Who carries the disk

Nobody in the middle. The source site publishes its export over HTTPS, and the target cluster's own importer fetches it directly. The disk never passes through Condensa, which needs no public address for this path and is not in the data path at all.

What must reach what	Why
Condensa → source site API (443)	Inventory, the export request, the power command
Condensa → target site API (443)	The migration-disk request, creating the VM
Target cluster nodes → source site API (443)	The actual disk transfer

The third row is the one people forget. Condensa can talk to both sites happily while the target's nodes cannot reach the source, and the migration then fails during the import, not at the start.

What each site needs

This is the property that makes the path usable against a site you do not control — proven against a customer's production platform, which needed no changes at all:

• Source — nothing new. The export, power, and inventory endpoints it already has are enough. No agent, no configuration, no restart.
• Target — a platform build that accepts POST /sa/virtualization/migration-disks. On an older build the migration fails at the first disk with a message naming the endpoint; upgrade the target, not the source.

The target must trust the source's certificate

The target's importer verifies the source's TLS certificate, and no provider setting relaxes it — a private CA on the source means installing that CA on the target cluster. Condensa checks this before it stops anything, so a failure here costs you nothing: the guest is still running and no export exists.

Add the CEP providers

You need two providers, one per site. Click the Provider tab, then Add Provider, and repeat:

1. Vendor — choose Awanio CEP.
2. Name — a display name that says which site it is (e.g. CEP Jakarta and CEP Surabaya). The Label tells apart several CEP providers in the wizard, so fill it in when you have more than two.
3. Under Connection Details:
   • Host — the site's API base URL, including the version segment: https://api.example.com/v2.
   • Access Key and Access Secret — the service account's credentials. They are encrypted at rest with CONDENSA_ENCRYPTION_KEY.
4. Click Create Provider, then Test Connection on the new card.

The same provider can act as a source or a target; nothing marks it as one or the other until you build a migration.

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 (a CEP site), then its Target Organization and, optionally, Target Project. There is no storage pool or target network to choose — a CEP target places the disk in the organization's storage.

Use Name Prefix when you are migrating a batch and want them recognisable on the target (migrated-). Leave it blank to keep names exactly as they are on the source, and rename individual guests in the review step instead.

Step 2 — Source provider

Select the other CEP site. There is no datacenter to pick — Condensa lists the whole site, one page at a time, filtered to the organization the service account can see.

Step 3 — Select guests

Pick one or more guests. Each row shows its power state, its Cold pill, its OS, address, and total disk size across every volume — not just the boot disk, so the number matches what actually has to move.

Step 4 — Review

Check the target and, under Per-VM Settings, the Target Name each guest will arrive under. Then click Create Migration.

The export, and how long it stands

When the migration starts, Condensa asks the source site to publish an export and gives it a lifetime sized from the work: the total disk size at an assumed floor of 4 MB/s, tripled for safety, never less than an hour and never more than 72 hours.

A guest too large to finish inside 72 hours is refused before anything is stopped, with the size and the assumed rate in the message. Migrate its disks separately, or move it over a link you can measure.

When the migration ends — success or failure — Condensa closes the export and its download token is revoked immediately rather than standing until the TTL. Against an older site with no delete endpoint, the export instead expires on its own; the log says which of the two happened.

Nothing is left behind on the source

After a successful migration the source site holds no export, no download token, and no snapshot. The only trace is the guest itself, stopped where it was.

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 and the progress bar climbs as a real percentage — the transfer reports its total size.
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.

When the bar says "size unknown"

Some sites publish only a compressed disk stream, which carries no total size. The bar then sweeps instead of counting, and the label reads size unknown — the transfer is healthy, it just cannot say how far along it is. It ends at 100% like any other.

What arrives on the target

A new VM in the target organization, with:

• the same CPU and memory as the source guest,
• every disk imported and attached in its original order, so the guest boots what it booted before,
• the OS type the source reported — from its OS variant where the site records one, and from the catalogue entry otherwise,
• a note recording that Condensa migrated it, and from which kind of source.

No network is attached

A migrated VM arrives with no network interface. Attach one on the target site before you start it, or it will boot without connectivity. Addresses do not follow a guest across sites in any case — the source's address belongs to the source's network.

Verify on the target

Open the target site's console, find the VM in the target organization, attach its network, and start it. Check inside the guest that its filesystems mounted and its services came up before you delete the source guest.

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