Catatan Rilis Condensa

Log ini mencatat pembaruan, fitur baru, dan perbaikan bug untuk Condensa.

---

Versi 1.6.2 (Agustus 2026)

Warm migration tidak lagi menghapus snapshot yang bukan buatannya. Selama ini ia menghapus semua snapshot di VM sumber, dua kali per migrasi — dan penghapusan pertama terjadi sebelum satu byte pun disalin. Operator yang mengambil snapshot sebagai jaring pengaman sebelum migrasi kehilangannya di langkah pertama, dan baru setelah itu penyalinan dimulai.

• Hanya checkpoint bernama condensa-warm-* yang dihapus. Apa pun selain itu dibiarkan persis seperti semula.
• Log migrasi menyebutkan berapa checkpoint miliknya sendiri yang dibersihkan, dan menyatakan bahwa snapshot lain tidak disentuh, sehingga batasnya terlihat, bukan diandaikan.
• Snapshot Anda tetap ada baik migrasinya berhasil maupun gagal.

Kalau Anda pernah menyimpan snapshot sebelum migrasi lalu mendapatinya hilang, inilah sebabnya. Tidak ada yang perlu dikonfigurasi — perilaku sebelumnya memang bukan sesuatu yang layak disediakan tombol matinya.

Change tracking diperiksa pada setiap disk sebelum data dipindahkan. vSphere mencatat change tracking di dua tempat: satu di VM dan satu di tiap disk, dan hanya setelan per-disk yang menentukan apakah sebuah disk bisa melaporkan blok yang berubah. Condensa hanya membaca yang tingkat-VM, sehingga warm migration bisa melaporkan change tracking siap, memindahkan data beberapa menit, lalu gagal pada disk yang sejak awal tidak mampu menyediakannya.

• Pemeriksaannya kini berjalan di detik-detik pertama dan menyebut disk lewat alamat bus-nya — scsi0:0, bukan nomor device internal.
• Bila sebuah disk belum siap, pesannya menyebutkan yang biasanya menyelesaikannya: matikan lalu nyalakan VM sekali agar setelan itu berlaku, atau migrasikan VM tersebut secara cold.
• Warm migration yang selama ini berjalan baik tidak terpengaruh.

Banner update memuat ulang halaman dengan sendirinya. Memasang update lewat banner dasbor dulu meminta Anda memuat ulang setelah beberapa detik. Kini ia menunggu restart dan memuat ulang sendiri, sebagaimana dialog About sudah lakukan, serta mengatakannya terang-terangan bila restart-nya lebih lama dari perkiraan.

---

Versi 1.6.1 (Agustus 2026)

Warm migration kini melaporkan konsistensi yang benar-benar dicapainya. Meminta snapshot quiesced ke vSphere dan tidak menerima error bukanlah hal yang sama dengan snapshot itu benar-benar quiesced: permintaannya tetap berhasil pada guest yang tidak menjalankan VMware Tools, dan snapshot-nya tetap crash-consistent. Condensa sekarang membaca kembali flag itu dari hypervisor dan melaporkan apa yang ditemukannya.

• Sebuah salinan disebut application-consistent hanya jika vSphere menyatakan snapshot-nya quiesced.
• Crash-consistent kini dinyatakan terang-terangan, tidak lagi lewat begitu saja, dan log menyebutkan apa yang akan mengubahnya — VMware Tools yang berjalan di dalam guest. Selama ini diam justru terbaca sebagai kabar baik.
• Bila flag itu tidak terbaca sama sekali, log mengatakannya, bukan memilih salah satu jawaban.

Ini paling penting untuk database dan apa pun yang mengandalkan titik waktu yang konsisten. Salinan crash-consistent sering kali sepenuhnya bisa dipakai; yang membuat administrator terkejut di saat terburuk adalah diberi tahu bahwa salinannya application-consistent padahal bukan.

Status update tidak lagi menjanjikan apa yang tidak bisa dipenuhi host. Instalasi tanpa komponen updater kini mengatakannya saat Anda memeriksa update, alih-alih menerima permintaan lalu menunggu restart yang tidak akan dilakukan siapa pun.

---

Versi 1.6.0 (Agustus 2026)

Provider kini dapat di-pin. Certificate self-signed pada alamat IP telanjang adalah kondisi yang lazim untuk instalasi on-prem dan air-gapped, bukan sekadar jalan pintas lab — dan sampai kini satu-satunya cara menghubunginya adalah menerima semua certificate, yang berarti menerima milik penyerang juga. Pinning memberi setelan yang selama ini hilang di antara keduanya: tanpa perlu certificate authority, dan tidak ada yang dipercaya begitu saja.

Instalasi 1.3.1–1.5.1 perlu satu kali update manual

Pada versi 1.3.1 sampai 1.5.1, tombol Install update tidak menyelesaikan tugasnya: dialognya terus menunggu dan menampilkan "the restart is taking longer than expected", atau sebuah error file system. Instalasi pada 1.3.0 dan sebelumnya tidak terpengaruh.

Naikkan instalasi seperti itu sekali secara manual. Hentikan service, ganti binary-nya dengan yang dari rilis ini, lalu jalankan kembali:

sudo systemctl stop condensa
curl -fLo /tmp/condensa.tar.gz <URL unduhan dari enterprise portal>
sudo tar -xzf /tmp/condensa.tar.gz -C /usr/local/bin condensa
sudo systemctl start condensa

Tidak ada yang perlu dikonfigurasi ulang: provider, kredensial, riwayat migrasi, dan kedua secret tidak tersentuh. Mulai 1.6.0 tombolnya bekerja kembali, dan rilis berikutnya memasang dirinya sendiri. Langkah lengkapnya ada di Updating.

Baru

• Tiga tingkat keamanan koneksi, ditampilkan bersama. Setiap form provider mengganti checkbox tunggal "allow insecure connection" dengan pilihan antara verifikasi terhadap certificate authority, pin endpoint ini, dan lewati verifikasi. Ketiganya berdampingan karena keputusannya adalah perbandingan — satu checkbox membuat "lewati verifikasi" tampak seperti opsi untuk self-signed, dan keyakinan itulah yang membuat koneksi tidak terlindungi.
• Fingerprint ditampilkan sebelum Anda menerimanya. Memilih Pin endpoint ini membaca apa yang disajikan server lalu menampilkan fingerprint, subject, issuer, masa berlaku, dan nama-namanya, sehingga keputusan diambil atas apa yang benar-benar ada di sana. Bandingkan dengan yang dilaporkan server itu sendiri sebelum menerima — membaca fingerprint hanya dari koneksi yang hendak Anda pin tidak membuktikan apa pun bila koneksi itu sudah disadap.
• Perpanjangan certificate tidak memutus pin. Condensa mem-pin public key milik server, bukan certificate-nya, sehingga penerbitan ulang — serial baru, masa berlaku baru, tambahan alamat di daftar — tetap berarti identitas yang sama. Hanya key yang benar-benar baru yang memicu mismatch, dan pesannya kemudian menampilkan kedua fingerprint berdampingan agar manusia bisa membedakan server yang dipasang ulang dari penyusup.
• SSH host key Proxmox di-pin secara terpisah. Data disk dibaca di node melalui SSH, tidak pernah lewat API Proxmox, sehingga certificate API tidak mengatakan apa pun tentang koneksi itu. Form Proxmox punya kontrol SSH host key tersendiri, lengkap dengan perintah ssh-keygen -lf untuk mengonfirmasi fingerprint langsung di node.

Perbaikan

• Pemeriksaan ruang staging memperkirakan dari ukuran yang diklaim sebuah volume, bukan dari isinya, sehingga disk 40 GiB yang isinya kurang dari satu gigabyte ditagih 80 GiB lalu ditolak. Diukur pada guest sungguhan, perkiraannya turun dari 82,0 GiB menjadi 3,9 GiB.
• Transfer yang mati tidak melaporkan apa pun yang bisa ditindaklanjuti operator. Kegagalannya kini membawa alasan yang diberikan host target, bukan sekadar migrasi yang berhenti.
• Disk Proxmox yang di-stage tertulis dua kali namanya di log migrasi.
• Appliance kini mempertahankan key-nya saat menerbitkan ulang certificate miliknya sendiri. Perpanjangan dulu mengubah identitas appliance, dan itu persis hal yang tidak bisa ditoleransi oleh pinning.
• Dua picker yang tersisa di wizard migrasi — target organization dan target project — berperilaku berbeda dari semua field lain: tidak bisa mengetik untuk memfilter, tidak ada navigasi keyboard. Keduanya kini seragam dengan bagian form lainnya.

Saat upgrade

• Provider yang sudah ada tidak berubah. Provider yang mengizinkan koneksi insecure tetap begitu; tidak ada yang tiba-tiba menolak koneksi yang sebelumnya diterima.
• Pinning bersifat opt-in per provider, dan dapat dimatikan lagi dengan mengosongkan pin-nya.
• Pada Proxmox, migrasi melalui SSH masih memerlukan Lewati verifikasi sampai Anda mem-pin SSH host key node tersebut. Setelah di-pin, keharusan itu hilang.

---

Versi 1.5.1 (Agustus 2026)

Instalasi kini tahu di mana mencari pembaruannya sendiri.

Perbaikan

• Instalasi yang tidak memiliki sumber update terkonfigurasi melaporkan bahwa pemeriksaan update otomatis dinonaktifkan, lalu menyebut sebuah environment variable kepada siapa pun yang membuka dialog About. Itu berlaku untuk sebagian besar instalasi, bukan segelintir yang tidak biasa: setelan tersebut hanya ditulis saat membuat instalasi baru, sehingga situs yang di-upgrade in-place tidak pernah menerimanya, begitu pula server yang dijalankan dengan tangan. Feed rilis kini ikut di dalam binary, jadi ia ditemukan tanpa perlu ada yang dikonfigurasi — dan dialog melaporkan pemeriksaan sebagai mati hanya ketika seseorang memang sengaja mematikannya.

Saat upgrade

• CONDENSA_UPDATE_URL tetap didahulukan bila diset, dan mengisinya dengan nilai kosong tetap mematikan pemeriksaan update. Situs yang tidak boleh menjangkau internet sebaiknya memastikan nilai itu kosong sebelum upgrade: instalasi yang selama ini diam hanya karena tidak ada yang dikonfigurasi akan mulai memeriksa rilis begitu berada di 1.5.1.

---

Versi 1.5.0 (Agustus 2026)

Awanio CEP bergabung dengan VMware dan Proxmox VE sebagai sumber migrasi. Guest berpindah dari satu situs Awanio CEP ke situs lain — mengonsolidasikan situs, pindah ke cluster Anda sendiri, atau meninggalkan sebuah penyedia. Situs sumber sama sekali tidak perlu diubah: endpoint yang sudah dimilikinya saja cukup, dan itulah yang membuat jalur ini bisa dipakai terhadap platform yang tidak Anda kelola. Mulai dari Awanio CEP sebagai sumber.

Baru

• Migrasi CEP ke CEP, cold. Situs sumber mempublikasikan disk sebuah guest dan importer milik cluster target mengambilnya langsung. Condensa mengorkestrasi tetapi tidak pernah membawa satu byte pun, sehingga jalur ini tidak memerlukan alamat publik. Guest yang berjalan dimatikan lebih dulu dan dibiarkan mati; salinan hasil migrasilah yang Anda jalankan di target.
• Jendela export diukur dari pekerjaannya, dan ditutup saat pekerjaan selesai. Condensa meminta masa berlaku yang diturunkan dari total ukuran disk, bukan angka tetap, menolak guest yang terlalu besar untuk selesai di dalamnya — sebelum ada yang dihentikan — dan menutup export saat migrasi berakhir, mencabut token unduhannya alih-alih membiarkannya hidup sampai jendelanya habis.
• Progres yang sebenarnya, dan transfer yang selamat dari gangguan. Disk diambil dalam bentuk yang melaporkan ukurannya, sehingga bar menghitung persentase yang benar alih-alih diam di nol, dan transfer yang terputus dilanjutkan dari titik berhentinya, bukan mengulang disk dari awal.

Perbaikan

• Progres sebuah migrasi hanya dihitung ulang saat selesai, sehingga bar menunjukkan 0% sepanjang transfer lalu melompat ke sukses. Kini ia diperbarui pada setiap polling, baik di daftar migrasi maupun di tampilan detail.
• Ketika sebuah transfer memang tidak dapat melaporkan total, bar kini menulis size unknown dan menyapu, alih-alih mengklaim 0% yang menyesatkan.
• Guest didaftarkan dengan nama yang ditampilkan situsnya. Mendaftarkan berdasarkan hostname membuat salinan hasil migrasi muncul dengan nama aslinya — dua baris identik yang hanya bisa dibedakan operator dari status daya.
• Inventaris guest dari situs CEP kini menelusuri seluruh situs alih-alih berhenti di sepuluh pertama, menjumlahkan setiap volume alih-alih disk boot saja, membaca alamat dalam setiap bentuk yang dilaporkan situs, dan jatuh kembali ke katalog ketika sebuah guest tidak mencatat OS variant.

Jalur migrasi yang didukung

Sumber	Target	Cold	Warm
VMware vSphere / ESXi	Awanio CEP	✓	✓ ¹
VMware vSphere / ESXi	Awanio Vapor (host tunggal)	✓	✓ ²
VMware vSphere / ESXi	Awanio Cockpit (fleet)	✓	✓ ²
Proxmox VE	Awanio Vapor (host tunggal)	✓	✓
Proxmox VE	Awanio Cockpit (fleet)	✓	✓
Proxmox VE	Awanio CEP	—	—
Awanio CEP	Awanio CEP	✓	— ³
Awanio CEP	Awanio Vapor atau Cockpit	—	—

¹ VM sumber perlu changed-block tracking (CBT) aktif dan sebuah snapshot yang sudah ada. ² Perlu toolchain VDDK terpasang di host target; VDDK juga memberi migrasi cold jalur langsung yang lebih cepat. ³ KubeVirt hanya mempublikasikan disk sebuah guest saat guest itu berhenti, dan tidak menyediakan changed-block tracking, sehingga jalur ini tidak punya varian warm.

Sebelum Anda upgrade

• Target CEP harus menjalankan build platform yang menerima disk migrasi. Pada build lama, migrasi berhenti di disk pertama dengan pesan yang menyebut endpoint-nya — upgrade targetnya, bukan sumbernya.
• Sumber CEP tidak memerlukan apa pun: tanpa agent, tanpa konfigurasi, tanpa restart. Terhadap sumber yang lebih lama, export sekadar kedaluwarsa sendiri alih-alih ditutup lebih awal, dan log mencatatnya.
• Node-node cluster target harus dapat menjangkau API situs sumber — Condensa yang menjangkau kedua situs saja tidak cukup, karena node-node itulah yang mengambil disknya.
• Tidak ada yang berubah untuk migrasi VMware atau Proxmox.

---

Versi 1.4.1 (Agustus 2026)

Migrasi Proxmox kini berjalan sepenuhnya di dalam jaringan privat. Migrasi cold dikonversi di node Proxmox itu sendiri dan ditulis langsung ke storage target, melalui kanal terautentikasi berumur pendek yang sama dengan yang sudah dipakai migrasi warm. Condensa mengorkestrasi tetapi tidak lagi membawa disknya — dan tidak lagi memerlukan alamat publik untuk sumber Proxmox sama sekali.

Baru

• Migrasi cold berjalan node-ke-target, apa pun format volumenya. Volume qcow2 maupun raw sama-sama dikonversi di node dan hanya mendarat di target — tanpa ruang gores di Condensa, dan blok yang tidak berisi apa-apa tidak pernah melintasi jaringan, sehingga volume yang sebagian besar kosong berpindah cepat dan tiba dalam keadaan thin. Bekerja sama baiknya ke satu host Vapor maupun ke fleet Cockpit.
• Rentang port migrasi dapat dipatok di target. Pada Vapor 3.0.2, aturlah di Host → System → Migration; aturan firewall antara node Proxmox dan host target menjadi satu rentang kecil alih-alih seluruh rentang ephemeral. Satu aturan kini mencakup warm dan cold, karena keduanya memakai kanal yang sama.
• Jalur jaringan yang terblokir adalah jalan memutar, bukan kegagalan. Sebelum ada data yang berpindah, node ditanya apakah ia dapat menjangkau port target. Bila tidak, log mengatakannya — menyebut alamat dan kemungkinan penyebabnya — dan migrasi dilanjutkan lewat jalur cadangan yang dibawa Condensa. Hanya jalur cadangan itulah yang memakai CONDENSA_PUBLIC_URL.

Jalur migrasi yang didukung

Sumber	Target	Cold	Warm
VMware vSphere / ESXi	Awanio CEP	✓	✓ ¹
VMware vSphere / ESXi	Awanio Vapor (host tunggal)	✓	✓ ²
VMware vSphere / ESXi	Awanio Cockpit (fleet)	✓	✓ ²
Proxmox VE	Awanio Vapor (host tunggal)	✓	✓
Proxmox VE	Awanio Cockpit (fleet)	✓	✓
Proxmox VE	Awanio CEP	—	—

¹ VM sumber perlu changed-block tracking (CBT) aktif dan sebuah snapshot yang sudah ada. ² Perlu toolchain VDDK terpasang di host target; VDDK juga memberi migrasi cold jalur langsung yang lebih cepat.

Sebelum Anda upgrade

• Migrasi Proxmox memerlukan Awanio Vapor 3.0.2 atau lebih baru di host target, dan Awanio Cockpit 3.0.1 atau lebih baru di depan sebuah fleet. Upgrade Vapor dari halaman update-nya sendiri sebelum bermigrasi.
• CONDENSA_PUBLIC_URL tidak lagi diperlukan untuk sumber Proxmox. Ia masih dipakai oleh migrasi cold VMware tanpa VDDK, dan oleh jalur cadangan Proxmox yang dijelaskan di atas.
• Tidak ada yang berubah untuk migrasi VMware.

---

Versi 1.4.0 (Agustus 2026)

Proxmox VE bergabung dengan VMware sebagai sumber migrasi. Guest berpindah keluar dari Proxmox VE menuju satu host yang dikelola Awanio Vapor, atau ke fleet yang dikelola Awanio Cockpit. Mulai dari Proxmox VE sebagai sumber.

Baru

• Migrasi dari Proxmox VE, warm maupun cold. Anda tidak memilih modenya: guest yang berjalan dicerminkan secara live lalu di-cutover dengan jeda dalam hitungan pecahan detik, guest yang mati disalin langsung. Tidak ada yang perlu diaktifkan di sisi Proxmox — tanpa changed-block tracking, tanpa snapshot yang dibuat manual. Setelah cutover berhasil, guest sumber dibiarkan dalam keadaan pause alih-alih dihapus, sehingga Anda dapat memverifikasi VM baru sebelum melepaskan yang lama.
• Setiap network interface ikut, bukan hanya yang pertama. Guest multi-homed mempertahankan seluruh interface-nya, masing-masing dengan MAC address yang dimilikinya di sumber, dan model adapter-nya di mana pun target dapat menyediakannya — sehingga konfigurasi di dalam guest yang mengikat berdasarkan MAC atau nama interface tetap bekerja.
• Kirim setiap network sumber ke tempat yang berbeda. Ketika guest yang Anda pilih berada di lebih dari satu bridge sumber, wizard menanyakan setiap bridge menjadi network target yang mana. Petakan keduanya terpisah untuk menjaga pemisahan yang diharapkan guest, atau petakan salah satunya ke tidak apa-apa untuk membiarkan interface itu tidak terpasang di VM baru.
• Ulangi migrasi yang gagal di tempat. Jalankan ulang dari menu aksi pada barisnya; percobaan sebelumnya tetap tersimpan di riwayat.
• Stream disk live terenkripsi, tanpa ada yang perlu disiapkan. Migrasi warm ke fleet Cockpit dilindungi mutual TLS. Target menerbitkan certificate-nya sendiri, Condensa menempatkan bagian milik sumber di node Proxmox selama migrasi berlangsung lalu menghapusnya setelah selesai.

Peningkatan

• Migrasi cold sebuah volume qcow2 tidak memerlukan ruang gores sama sekali — ia mengalir dari node Proxmox ke target sembari dibaca. Volume yang tersimpan sebagai raw (LVM-thin, ZFS, Ceph RBD) masih melewati Condensa, dan kini diperiksa sebelum dimulai: migrasi yang tidak akan muat ditolak di awal dengan menyebut kekurangannya, dan hanya satu yang berjalan pada satu waktu sehingga beberapa guest besar mengantre alih-alih memenuhi disk bersamaan.
• Migrasi warm ke target di jaringan lain. Set CONDENSA_TARGET_WARM_ADDRESS ketika alamat host target yang dikenal jaringan manajemen Anda bukan alamat yang dapat dijangkau sumber. Lihat Migrasi warm ke fleet Cockpit.
• Masalah dilaporkan sebelum pekerjaan, bukan sesudahnya. Jika target akan menolak mengunduh dari Condensa ini, atau node Proxmox tidak dapat menjangkau port disk-stream target, migrasi mengatakannya di awal — menyebut alamat dan apa yang perlu diubah — alih-alih setelah satu jam menyalin. Lihat Apa yang harus menjangkau apa.
• Cutover warm bersifat application-consistent bila memungkinkan. Dengan qemu-guest-agent berjalan di dalam guest, filesystem-nya di-quiesce pada saat cutover; tanpa itu cutover bersifat crash-consistent dan log mencatat yang mana dari keduanya yang terjadi.

Perbaikan bug

• Migrasi yang selesai menampilkan kapan ia selesai. Migrasi yang sukses menampilkan "Completed at: In Progress" di samping lencana hijaunya, dan yang dibatalkan tidak pernah mencatat waktu berakhir sama sekali.
• Transfer yang lama tidak lagi disalahartikan sebagai transfer yang macet. Disk besar yang sedang menyalin dengan baik bisa digagalkan beberapa menit sebelum rampung.
• Migrasi warm mengembalikan sumber daya guest sumber. Migrasi warm yang gagal atau dibatalkan dulu meninggalkan sebuah block device terdaftar di dalam guest sumber yang sedang berjalan, yang kemudian memblokir setiap percobaan berikutnya pada disk yang sama — dan hanya me-restart guest yang membersihkannya, justru hal yang ingin dihindari oleh migrasi warm.
• VM hasil migrasi mempertahankan bus disk yang diharapkan guest-nya, sehingga guest yang boot image-nya hanya membawa satu driver storage tetap menemukan disk root-nya.
• Daftar migrasi menyebut sumber yang sebenarnya. Setiap migrasi dilabeli berasal dari VMware terlepas dari asal sebenarnya.

Sebelum Anda upgrade

• Migrasi warm ke fleet Cockpit memerlukan Awanio Vapor 3.0.1 atau lebih baru dan Awanio Cockpit 3.0.1 atau lebih baru di sisi target.
• Periksa Apa yang harus menjangkau apa sebelum merencanakan aturan firewall: mesin mana yang membawa disk berbeda menurut sumber, target, dan metodenya, dan itulah yang menentukan aturan yang Anda perlukan.
• Tidak ada dalam rilis ini yang mengubah perilaku deployment yang sudah ada. CONDENSA_TARGET_WARM_ADDRESS bersifat opsional dan default-nya sama dengan perilaku Condensa sebelumnya.

---

Versi 1.3.2 (Juli 2026)

Rilis pemeliharaan tanpa perubahan pada cara migrasi berjalan: ia memperbaiki alur publikasi yang dipakai untuk mengirimkan pembaruan Condensa.

---

Versi 1.3.1 (Juli 2026)

Rilis keandalan untuk migrasi VMware pada VM yang besar, bermulti-disk, dan berjalan lama.

Perbaikan bug

• VM BIOS multi-disk boot tanpa perbaikan manual: VM hasil migrasi dengan beberapa disk (boot legacy/BIOS) kini langsung boot — disk sistem operasi ditempatkan pertama secara otomatis, sehingga Anda tidak perlu lagi membetulkan urutan boot dengan tangan setelah migrasi.
• Migrasi panjang tetap terhubung: Migrasi yang berjalan lama — disk besar, atau transfer warm — tidak lagi gagal menjelang akhir dengan error "session is not authenticated". Koneksi ke VMware dijaga tetap hidup dan dibangun ulang sesuai kebutuhan, sehingga cutover terakhir rampung dengan andal. (Migrasi cold tidak pernah terdampak.)