Awanio CEP sebagai sumber

Panduan ini membahas migrasi guest keluar dari satu site Awanio CEP menuju site Awanio CEP lain — dari cluster yang menjalankan platform Awanio ke cluster lain yang juga menjalankannya. Sisi target pada wizard sama dengan yang dijelaskan di VMware to CEP; semua yang berbeda ada di sisi sumber dan dijelaskan di sini.

Target Vapor dan Cockpit tidak tersedia untuk sumber CEP. Pilih target CEP.

Sebelum mulai

• Sign in to Condensa dari halaman overview.
• Siapkan service account di masing-masing site — satu di sumber, satu di target — beserta access key dan secret-nya.
• Site target harus menjalankan build platform yang menerima migration disk (lihat Apa yang dibutuhkan setiap site). Site sumber tidak memerlukan apa pun yang baru.
• Rencanakan downtime untuk setiap guest yang Anda migrasikan: jalur ini cold saja.

Hanya cold, dan alasannya

Sebuah site menyajikan disk milik guest lewat KubeVirt VirtualMachineExport, dan KubeVirt hanya menerbitkannya selagi guest dalam keadaan mati. Tidak ada changed-block tracking sebagai cadangan, sehingga tidak ada varian warm untuk jalur ini.

Condensa menyampaikannya sebelum Anda memutuskan: langkah 3 pada wizard memuat pemberitahuan tersebut, dan setiap guest menampilkan pill Cold.

Kondisi guest saat migrasi dimulai	Yang terjadi
Mati	Disk-nya di-export dan langsung disalin.
Berjalan	Condensa mematikannya lebih dulu, menunggu sampai benar-benar berhenti, lalu meng-export. Guest dibiarkan tetap mati setelahnya.

Salinan hasil migrasi itulah yang Anda jalankan di target. Guest sumber tetap di tempatnya, dalam keadaan mati — tidak ada yang dihapus, jadi rollback cukup dengan menyalakannya kembali.

Guest yang berjalan dimatikan tanpa konfirmasi kedua

Memilih guest yang sedang berjalan adalah keputusannya. Condensa memberi waktu hingga lima menit untuk berhenti dengan bersih dan melaporkan guest yang tidak mau berhenti; Condensa tidak pernah mematikannya secara paksa. Matikan sendiri apa pun yang punya service yang perlu di-flush, pada waktu yang Anda pilih.

Siapa yang membawa disk

Tidak ada perantara. Site sumber menerbitkan export-nya lewat HTTPS, dan importer milik cluster target sendiri yang mengambilnya langsung. Disk tidak pernah melewati Condensa, yang untuk jalur ini tidak memerlukan alamat publik dan sama sekali tidak berada di jalur data.

Apa harus menjangkau apa	Alasan
Condensa → API site sumber (443)	Inventory, permintaan export, perintah power
Condensa → API site target (443)	Permintaan migration-disk, pembuatan VM
Node cluster target → API site sumber (443)	Transfer disk yang sebenarnya

Baris ketiga inilah yang sering terlupakan. Condensa bisa saja berkomunikasi lancar dengan kedua site sementara node target tidak dapat menjangkau sumber, dan migrasi kemudian gagal saat import, bukan di awal.

Apa yang dibutuhkan setiap site

Inilah sifat yang membuat jalur ini bisa dipakai terhadap site yang tidak Anda kendalikan — sudah terbukti pada platform produksi milik pelanggan, yang sama sekali tidak perlu diubah:

• Sumber — tidak ada yang baru. Endpoint export, power, dan inventory yang sudah dimilikinya sudah cukup. Tanpa agent, tanpa konfigurasi, tanpa restart.
• Target — build platform yang menerima POST /sa/virtualization/migration-disks. Pada build lama, migrasi gagal di disk pertama dengan pesan yang menyebut endpoint tersebut; upgrade sisi target, bukan sisi sumber.

Target harus mempercayai sertifikat milik sumber

Importer di target memverifikasi sertifikat TLS milik sumber, dan tidak ada setelan provider yang melonggarkannya — private CA di sisi sumber berarti CA tersebut harus dipasang di cluster target. Condensa memeriksa hal ini sebelum mematikan apa pun, jadi kegagalan di titik ini tidak merugikan Anda: guest masih berjalan dan belum ada export yang dibuat.

Menambahkan provider CEP

Anda memerlukan dua provider, satu untuk tiap site. Klik tab Provider, lalu Add Provider, dan ulangi:

1. Vendor — pilih Awanio CEP.
2. Name — nama tampilan yang menunjukkan site mana (mis. CEP Jakarta dan CEP Surabaya). Label membedakan beberapa provider CEP di dalam wizard, jadi isilah bila Anda punya lebih dari dua.
3. Pada Connection Details:
   • Host — base URL API site tersebut, termasuk segmen versinya: https://api.example.com/v2.
   • Access Key dan Access Secret — kredensial milik service account. Keduanya dienkripsi saat disimpan dengan CONDENSA_ENCRYPTION_KEY.
4. Klik Create Provider, lalu Test Connection pada card yang baru muncul.

Provider yang sama dapat berperan sebagai sumber maupun target; tidak ada yang menandainya sebagai salah satu sampai Anda membuat sebuah migrasi.

Membuat migrasi

Klik tab Migrations, lalu Create Migration.

Langkah 1 — Info dasar dan target

Isi Migration Name, pilih Target Provider (sebuah site CEP), lalu Target Organization dan, opsional, Target Project. Tidak ada storage pool atau target network yang perlu dipilih — target CEP menempatkan disk pada storage milik organization tersebut.

Gunakan Name Prefix bila Anda memigrasikan banyak guest sekaligus dan ingin mudah mengenalinya di target (migrated-). Kosongkan untuk mempertahankan nama persis seperti di sumber, dan ganti nama guest satu per satu di langkah review sebagai gantinya.

Langkah 2 — Provider sumber

Pilih site CEP yang satunya. Tidak ada datacenter yang perlu dipilih — Condensa menampilkan seluruh isi site, satu halaman setiap kali, terbatas pada organization yang dapat dilihat oleh service account.

Langkah 3 — Memilih guest

Pilih satu guest atau lebih. Setiap baris menampilkan power state, pill Cold, OS, alamat, dan total ukuran disk dari seluruh volume — bukan hanya boot disk, sehingga angkanya sesuai dengan yang benar-benar harus dipindahkan.

Langkah 4 — Review

Periksa targetnya dan, pada Per-VM Settings, Target Name yang akan dipakai setiap guest. Lalu klik Create Migration.

Export, dan berapa lama ia bertahan

Saat migrasi dimulai, Condensa meminta site sumber menerbitkan sebuah export dan memberinya masa hidup yang dihitung dari beban kerjanya: total ukuran disk pada asumsi laju minimum 4 MB/s, dikalikan tiga sebagai margin aman, tidak pernah kurang dari satu jam dan tidak pernah lebih dari 72 jam.

Guest yang terlalu besar untuk selesai dalam 72 jam akan ditolak sebelum ada yang dimatikan, disertai ukuran dan laju asumsinya di dalam pesan. Migrasikan disk-nya secara terpisah, atau pindahkan lewat jalur yang lajunya dapat Anda ukur.

Ketika migrasi berakhir — sukses maupun gagal — Condensa menutup export tersebut dan token download-nya dicabut seketika, tidak dibiarkan bertahan sampai TTL habis. Terhadap site lama yang tidak punya endpoint delete, export justru kedaluwarsa dengan sendirinya; log menyebutkan mana dari keduanya yang terjadi.

Tidak ada yang tertinggal di sumber

Setelah migrasi sukses, site sumber tidak menyimpan export, token download, maupun snapshot. Satu-satunya jejak adalah guest itu sendiri, dalam keadaan mati di tempatnya semula.

Menjalankan dan memantau migrasi

1. Buka menu aksi (titik tiga di sebelah kanan baris) lalu pilih Start Migration.
2. Status berubah menjadi Running dan progress bar naik sebagai persentase sungguhan — transfernya melaporkan ukuran total.
3. Setelah selesai, status menjadi Success. Klik nama migrasi untuk melihat detail per disk beserta log-nya.

Migrasi yang gagal dapat dijalankan ulang dari menu aksi yang sama dengan Retry.

Ketika progress bar menyebut "size unknown"

Sebagian site hanya menerbitkan stream disk terkompresi, yang tidak membawa informasi ukuran total. Progress bar lalu bergerak bolak-balik alih-alih menghitung, dan labelnya berbunyi size unknown — transfernya sehat, hanya saja tidak bisa menyatakan sudah sejauh mana. Ia tetap berakhir di 100% seperti transfer lainnya.

Apa yang tiba di target

Sebuah VM baru di organization target, dengan:

• CPU dan memory yang sama seperti guest sumber,
• seluruh disk ter-import dan terpasang dalam urutan aslinya, sehingga guest mem-boot apa yang sebelumnya ia boot,
• OS type sesuai yang dilaporkan sumber — dari OS variant bila site mencatatnya, dan dari entri catalogue bila tidak,
• sebuah catatan bahwa VM ini dimigrasikan oleh Condensa, dan dari jenis sumber apa.

Tidak ada network yang terpasang

VM hasil migrasi tiba tanpa network interface. Pasang satu di site target sebelum Anda menyalakannya, atau ia akan boot tanpa konektivitas. Lagi pula alamat tidak ikut berpindah bersama guest antar-site — alamat milik sumber adalah milik network sumber.

Verifikasi di target

Buka console site target, temukan VM tersebut di organization target, pasang network-nya, lalu nyalakan. Periksa di dalam guest bahwa filesystem-nya sudah ter-mount dan service-nya sudah berjalan sebelum Anda menghapus guest sumber.

Untuk lisensi berbasis kredit dan bagaimana migrasi mengonsumsi kredit, lihat Lisensi.