Integrasi dengan Awanio Cockpit

Dengan target Cockpit, Condensa memigrasikan VM ke armada host KVM yang dikelola control plane Cockpit. Anda memilih host target, storage pool, dan network per migrasi, dan job transfer migrasi otomatis muncul di panel Tasks Cockpit.

Prasyarat

• Control plane Cockpit yang berjalan dan terjangkau dari server Condensa lewat HTTPS.
• Host target sudah terdaftar di Cockpit (lewat alur provisioning host Cockpit yang normal).
• Service account Cockpit (access key + secret) untuk Condensa.
• Untuk transfer direct-pull dan warm migration: VDDK terpasang di host target dan akses jaringan dari host-host itu ke ESXi — lihat Tentang VDDK.
• Untuk fallback staged (dipakai otomatis bila host tanpa VDDK; hanya cold): host harus bisa menjangkau CONDENSA_PUBLIC_URL.

1. Buat service account di Cockpit

Di Cockpit, buat service account untuk Condensa dan catat access key beserta secret-nya.

2. Daftarkan provider di Condensa

1. Buka Providers → Add Provider.
2. Pilih vendor Awanio Cockpit.
3. Isi:
   • Label — nama yang mudah dikenali di wizard (mis. cockpit-prod)
   • API URL — base API Cockpit, mis. https://cockpit.example.com/api/v1 (origin saja juga bisa — Condensa menambahkan /api/v1)
   • Access key / secret — kredensial service account
4. Simpan, lalu klik Test pada kartu provider — harus sukses sebelum migrasi bisa berjalan.

3. Jalankan migrasi

Di wizard migrasi pilih sumber VMware, pilih VM-nya, lalu:

• Target provider — provider Cockpit yang tadi didaftarkan
• Target host — host KVM yang menerima VM
• Storage pool — tempat disk qcow2 hasil konversi diletakkan
• Network — switch tempat NIC VM disambungkan (default None, untuk menghindari konflik IP dengan sumber yang masih hidup)

Warm migration ditawarkan untuk VM VMware yang menyala dengan CBT tersedia; wizard menandai kesiapan setiap VM.

Bagaimana data berpindah

Engine	Jalur	Dipakai ketika
VDDK direct pull	Host target menarik dari ESXi, konversi qcow2 on-the-fly	Host punya VDDK (diutamakan; wajib untuk warm)
Staged transfer	Condensa ekspor via vSphere, konversi, host mengunduh	Fallback otomatis, cold saja

Engine yang benar-benar dipakai ditampilkan di halaman detail migrasi sebagai badge Method.

Firmware (UEFI/BIOS) dan Secure Boot

Condensa mendeteksi firmware boot VM sumber dan membuat target yang cocok — guest UEFI mendapat target UEFI (OVMF), guest lawas mendapat BIOS. Ini otomatis; sumber UEFI dicatat di log migrasi. Tidak ada tindakan yang diperlukan agar VM boot dengan firmware yang benar.

Secure Boot sengaja dibiarkan mati pada VM hasil migrasi. State Secure Boot berada di NVRAM firmware, bukan di disk, jadi ia tidak ikut berpindah bersama disk. Menyalakannya pada NVRAM target yang baru — yang enrolled keys dan build OVMF-nya bisa jadi tidak cocok dengan tanda tangan guest — sering justru menggagalkan boot. Guest yang dulu diinstall di bawah Secure Boot tetap boot normal saat Secure Boot mati: Secure Boot hanya memverifikasi tanda tangan boot, bukan syarat untuk boot.

Jika ada guest yang benar-benar memerlukan Secure Boot (mis. kebijakan kepatuhan), nyalakan pada VM tersebut di Cockpit, setelah migrasi:

1. Matikan (power off) VM hasil migrasi di Cockpit.
2. Buka VM dan edit Firmware & Options.
3. Aktifkan Secure Boot — dan TPM bila guest membutuhkannya (mis. Windows 11). Secure Boot memerlukan tipe mesin q35 pada x86_64.
4. Pastikan host target sudah punya firmware OVMF yang mendukung Secure Boot.
5. Nyalakan VM.

Lihat Cockpit → Virtual Machines untuk kontrol Firmware & Options.

Windows + BitLocker

Bila guest memakai BitLocker yang terikat ke TPM/Secure Boot, perubahan firmware apa pun dapat memicu permintaan recovery key BitLocker sekali pada boot berikutnya. Siapkan recovery key sebelum mengubah pengaturan firmware.

Pemecahan masalah

• Test provider gagal — periksa API URL, kredensial service account, dan penerimaan sertifikat TLS Cockpit.
• Job import gagal dengan error thumbprint/VDDK — pastikan VDDK di host target (UI Vapor → System → Third-party Libraries) dan host bisa menjangkau ESXi di port 443/902.
• Staged transfer terpakai padahal mengharapkan direct pull — host target tidak punya VDDK atau tak bisa menjangkau ESXi; migrasi tetap selesai secara cold via staging.
• VM hasil migrasi menampilkan "no bootable device" / disk kosong — firmware target harus cocok dengan sumber. Condensa mengaturnya otomatis, tetapi migrasi yang dibuat sebelum fitur pembawaan firmware ada akan default ke BIOS. Buat ulang migrasinya agar firmware sumber terdeteksi, atau ubah firmware VM ke UEFI di Cockpit (Firmware & Options).