Integrate with Awanio Cockpit

With a Cockpit target, Condensa migrates VMs onto the fleet of KVM hosts managed by the Cockpit control plane. You choose the target host, storage pool, and network per migration, and migration transfer jobs appear in Cockpit's Tasks panel automatically.

Prerequisites

• A running Cockpit control plane, reachable from the Condensa server over HTTPS.
• The target hosts are registered in Cockpit (added through Cockpit's normal host-provisioning flow).
• A Cockpit service account (access key + secret) for Condensa.
• For direct-pull transfers and warm migration: VDDK installed on the target hosts and network access from those hosts to ESXi — see About VDDK.
• For the staged fallback (used automatically when a host has no VDDK; cold migrations only): the hosts must be able to reach CONDENSA_PUBLIC_URL.

1. Create a service account in Cockpit

In Cockpit, create a service account for Condensa and note its access key and secret.

2. Register the provider in Condensa

1. Go to Providers → Add Provider.
2. Choose vendor Awanio Cockpit.
3. Fill in:
   • Label — a name you'll recognize in the wizard (e.g. cockpit-prod)
   • API URL — the Cockpit API base, e.g. https://cockpit.example.com/api/v1 (the origin alone also works — Condensa appends /api/v1)
   • Access key / secret — the service account credentials
4. Save, then click Test on the provider card — it must report success before migrations can run.

3. Run a migration

In the migration wizard select your VMware source, pick the VMs, then:

• Target provider — the Cockpit provider you registered
• Target host — which KVM host receives the VM
• Storage pool — where the converted qcow2 disks land
• Network — the switch the VM's NIC attaches to (default None, to avoid IP conflicts with a still-running source)

Warm migration is offered for powered-on VMware VMs with CBT available; the wizard flags each VM's readiness.

How the data moves

Engine	Path	Used when
VDDK direct pull	Target host pulls from ESXi, converts to qcow2 on the fly	Host has VDDK (preferred; required for warm)
Staged transfer	Condensa exports via vSphere, converts, host downloads	Automatic fallback, cold only

The engine that actually ran is shown on the migration detail page as the Method badge.

Firmware (UEFI/BIOS) and Secure Boot

Condensa detects the source VM's boot firmware and creates the target to match — a UEFI guest gets a UEFI (OVMF) target, a legacy guest gets BIOS. This is automatic; a UEFI source is noted in the migration log. No action is needed for the VM to boot with the correct firmware.

Secure Boot is deliberately left off on the migrated VM. Secure Boot state lives in the firmware's NVRAM, not on the disk, so it does not travel with the migrated disk. Turning it on against a fresh target NVRAM — whose enrolled keys and OVMF build may not match what the guest was signed against — commonly prevents boot. A guest that was installed under Secure Boot still boots normally with it off: Secure Boot only verifies boot signatures, it is not required to boot.

If a specific guest genuinely requires Secure Boot (for example a compliance policy), enable it on the VM in Cockpit, after migration:

1. Power off the migrated VM in Cockpit.
2. Open the VM and edit Firmware & Options.
3. Enable Secure Boot — and TPM if the guest needs it (e.g. Windows 11). Secure Boot requires the q35 machine type on x86_64.
4. Make sure the target host has a Secure Boot-capable OVMF firmware installed.
5. Start the VM.

See Cockpit → Virtual Machines for the Firmware & Options controls.

Windows + BitLocker

If the guest uses BitLocker tied to TPM/Secure Boot, any firmware change can trigger a one-time BitLocker recovery-key prompt on next boot. Have the recovery key on hand before changing firmware settings.

Troubleshooting

• Provider test fails — check the API URL, service account credentials, and that Cockpit's TLS certificate is accepted.
• Import jobs fail with a thumbprint/VDDK error — verify VDDK on the target host (Vapor UI → System → Third-party Libraries) and that the host can reach ESXi on port 443/902.
• Staged transfer used when you expected direct pull — the target host has no VDDK or cannot reach ESXi; the migration still completes cold via staging.
• Migrated VM shows "no bootable device" / an empty disk — the target firmware must match the source. Condensa sets this automatically, but migrations created before firmware carry-over was added default to BIOS. Re-create the migration so the source firmware is detected, or switch the VM's firmware to UEFI in Cockpit (Firmware & Options).