Saya memiliki Proxmox cluster yang terdiri dari pveceph1 dan pveceph2, dengan tiga OSD Ceph pada setiap node. Agar cluster tetap dapat dikelola dan storage Ceph tetap melayani I/O ketika salah satu node mati, saya menambahkan server Debian eksternal bernama cephmon3.
Server tersebut menjalankan dua layanan berbeda:
Ceph MON ketiga untuk menjaga quorum Ceph.
Corosync qnetd untuk memberikan vote QDevice kepada cluster PVE.
Ceph MON tidak menggantikan QDevice karena keduanya menangani quorum yang berbeda.
Topologi
Host
Layanan
pveceph1
PVE, MON, MGR, 3 OSD
pveceph2
PVE, MON, MGR, 3 OSD
cephmon3
Debian, MON, qnetd, tanpa OSD
cephmon3 harus berada pada server atau hypervisor independen. Jangan menyimpannya pada pveceph1, pveceph2, atau pool Ceph yang sama.
1. Memastikan MON dan MGR pada kedua node
Dari GUI Proxmox, buka node > Ceph > Monitor. Pastikan layanan berikut sudah terdaftar:
MON pada pveceph1 dan pveceph2.
MGR pada pveceph1 dan pveceph2, dengan satu active dan satu standby.
Jika ada yang belum tersedia, pilih node terkait lalu klik Create pada bagian Monitor atau Manager.
Lanjutkan ketika kedua MON PVE sudah berada dalam quorum.
2. Menyiapkan server cephmon3
Saya menggunakan Debian 13 minimal dengan 2 vCPU, RAM 4 GB, disk lokal 32 GB, IP statis, SSH server, dan tanpa desktop environment.
Pastikan hostname konsisten:
hostnamectl set-hostname cephmon3
hostnamectl
Tambahkan resolusi hostname ketiga server melalui DNS internal atau /etc/hosts. Pastikan waktu tersinkronisasi:
Jika Debian dipasang menggunakan ISO DVD, nonaktifkan sumber deb cdrom: dan pastikan repository online Debian Trixie sudah aktif sebelum menjalankan apt update.
3. Mengatur firewall (untuk production)
Untuk lingkungan produksi, firewall sebaiknya tetap aktif dan hanya membuka koneksi yang diperlukan:
Port
Arah
Fungsi
TCP 3300 dan 6789
Antara ketiga host MON
Komunikasi Ceph MON
TCP 5403
pveceph1/pveceph2 ke cephmon3
Corosync qnetd
TCP 22
Jaringan administrator ke cephmon3
SSH administrasi
Jika menggunakan Proxmox Firewall, tambahkan rule Ceph pada kedua node PVE dan izinkan IP cephmon3. Pada server Debian, izinkan IP kedua node PVE menuju port MON dan qnetd.
Untuk lab lokal yang terisolasi, firewall dapat dinonaktifkan sementara agar pengujian lebih mudah. Namun, jangan menggunakan cara tersebut pada lingkungan produksi dan aktifkan kembali firewall setelah pengujian selesai.
ID MON harus konsisten. Karena service bernama ceph-mon@cephmon3, direktori datanya harus bernama ceph-cephmon3 dan konfigurasi menggunakan [mon.cephmon3].
Dengan QDevice, pvecm expected 1 tidak perlu digunakan sebagai konfigurasi permanen.
8. Memeriksa konfigurasi pool
Untuk cluster dengan OSD hanya pada dua host, pool dibuat terlebih dahulu dengan size 3/min_size 2, kemudian diedit menjadi size 2/min_size 1 pada pvecephpool dan .mgr.
ceph osd pool get pvecephpool size
ceph osd pool get pvecephpool min_size
ceph osd pool get .mgr size
ceph osd pool get .mgr min_size
Nilai min_size 1 membuat storage tetap menerima I/O dari satu replika ketika satu node OSD mati, tetapi Ceph akan berada dalam kondisi degraded dan risiko kehilangan data meningkat.
9. Melakukan pengujian
Matikan salah satu node PVE melalui GUI, kemudian periksa dari node yang masih hidup:
pvecm status
ceph -s
ceph mon stat
Hasil yang diharapkan:
PVE tetap quorate menggunakan satu node dan QDevice.
Ceph tetap memiliki quorum melalui satu MON PVE dan cephmon3.
VM pada node yang masih hidup tetap berjalan.
Storage tetap dapat menerima I/O, tetapi berstatus degraded sampai node kedua kembali.
VM pada node yang mati hanya dapat otomatis menyala di node lainnya jika telah dikonfigurasi sebagai resource HA dan kapasitas node yang tersisa mencukupi.
Kesimpulan
Penambahan cephmon3 menyelesaikan dua kebutuhan pada cluster dua node: Ceph memperoleh MON ketiga, sedangkan Proxmox memperoleh vote tambahan dari QDevice. Solusi ini dapat menggunakan Debian ringan tanpa menambah node PVE ketiga, tetapi tetap merupakan desain kompromi karena data OSD hanya tersimpan pada dua host.
Beberapa waktu lalu saya diminta melakukan pengujian migrasi NAKIVO Backup & Replication ke server baru. Tujuan pengujian ini adalah memastikan apakah konfigurasi seperti inventory, credentials, job backup, job replikasi, dan schedule dapat dipindahkan tanpa harus dibuat ulang.
Pengujian dilakukan menggunakan dua server, yaitu nakivo sebagai server lama dan nakivo2 sebagai server baru. Inventory yang dikelola terdiri dari dua server Proxmox, yaitu pve-nakivo dan pve-nakivo2, dengan backup tersimpan pada Onboard Repository.
Memahami Cakupan System Configuration
NAKIVO menyediakan fitur Export System Configuration untuk memindahkan konfigurasi Director ke instance baru. Berdasarkan dokumentasi NAKIVO, konfigurasi yang ikut dipindahkan mencakup inventory, job, credentials, dan Transporter settings.
Pada pengujian ini, konfigurasi berikut berhasil terbawa ke NAKIVO baru:
Inventory Proxmox yang sudah didaftarkan.
Credentials.
Backup job dan replication job.
Schedule dan retention setiap job.
Konfigurasi Transporter.
Referensi atau konfigurasi Backup Repository.
Namun, export system configuration tidak membawa data fisik yang tersimpan di Backup Repository. Artinya, file backup dan recovery point tetap berada di storage server lama dan harus dipindahkan secara terpisah.
Fitur ini juga ditujukan untuk migrasi, bukan sebagai backup konfigurasi rutin. Saat export dilakukan, aktivitas yang sedang berjalan akan dihentikan dan seluruh job pada NAKIVO lama akan dinonaktifkan. Setelah export, sebaiknya jangan menjalankan kembali job pada instance lama jika migrasi akan dilanjutkan ke instance baru.
Sebelum export, saya memastikan tidak ada proses backup, replikasi, recovery, maupun repository maintenance yang sedang berjalan.
Proses export dilakukan melalui menu berikut:
Buka Settings.
Masuk ke General > System Settings.
Pilih tab Configuration.
Klik Export System Configuration.
Pilih Include indexing data jika data indexing juga ingin dipindahkan.
Pilih Encrypt system configuration untuk melindungi credentials di dalam bundle.
Masukkan password, kemudian jalankan export.
Download export bundle setelah proses selesai.
NAKIVO lama kemudian tidak digunakan untuk menjalankan job agar tidak terjadi perbedaan status antara Director lama dan Director baru.
Import Konfigurasi ke NAKIVO Baru
Pada nakivo2, saya memasang NAKIVO Backup & Replication dengan versi dan build yang sama. Import dilakukan melalui:
Buka Settings.
Masuk ke General > System Settings.
Pilih tab Configuration.
Klik Import System Configuration.
Pilih export bundle dari server lama.
Masukkan password bundle.
Klik Import, kemudian Proceed.
Setelah proses selesai, inventory, credentials, backup job, replication job, dan schedule dari NAKIVO lama muncul pada NAKIVO baru. Konfigurasi yang sudah ada sebelumnya pada server baru akan ditimpa oleh konfigurasi dari bundle.
Memindahkan Data Onboard Repository
Walaupun konfigurasi repository sudah terbawa, data backup belum berada pada server baru. Dan masih menunjukkan issue
Lokasi repository pada server lama adalah:
/opt/nakivo/repository/NakivoBackup
Pada server baru, repository saya tempatkan di:
/backup-nakivo/NakivoBackup
Sebelum menyalin data, repository harus dipastikan tidak sedang digunakan oleh job dan sebaiknya di-detach terlebih dahulu. Seluruh folder NakivoBackup kemudian disalin tanpa mengubah atau menghapus file di dalamnya.
Saya memilih menyalin data terlebih dahulu, bukan langsung menghapus repository lama. Dengan demikian, salinan lama masih dapat digunakan sebagai cadangan sampai repository baru berhasil diverifikasi.
Repository hasil import kemudian diedit melalui Settings > Repositories. Assigned Transporter diarahkan ke Onboard Transporter milik nakivo2, sedangkan path diisi dengan:
/backup-nakivo
Path yang dimasukkan adalah direktori induk, bukan /backup-nakivo/NakivoBackup, karena NAKIVO akan mencari folder NakivoBackup di dalam lokasi tersebut.
Jika repository tidak muncul setelah import, repository dapat didaftarkan melalui Settings > Repositories > Add existing backup repository. Pilih Local Folder, tentukan Transporter, lalu masukkan path /backup-nakivo.
Saat menjalankan self-healing, muncul error berikut:
Self-healing of the "Onboard Repository" has failed
Reason: The "Onboard transporter" transporter cannot read and/or
write to the specified location (/backup-nakivo).
Pemeriksaan permission menunjukkan kondisi berikut:
# Server lama
drwxrwxrwx root root /opt/nakivo/repository
drwxrwx--- bhsvc bhsvc /opt/nakivo/repository/NakivoBackup
# Server baru
drwxr-xr-x root root /backup-nakivo
drwxrwx--- bhsvc bhsvc /backup-nakivo/NakivoBackup
Folder NakivoBackup sudah dimiliki oleh bhsvc, tetapi folder induk /backup-nakivo masih dimiliki root:root dengan permission 755. Akibatnya, Onboard Transporter dapat membuka folder tersebut, tetapi tidak memiliki hak tulis pada lokasi yang didaftarkan sebagai repository.
Permission dapat disamakan seperti server lama menggunakan chmod 777, tetapi pilihan yang lebih aman adalah memberikan akses hanya kepada user dan grup service NAKIVO:
Sebelum mengaktifkan kembali seluruh schedule, beberapa pemeriksaan yang perlu dilakukan adalah:
Inventory Proxmox dapat di-refresh.
Onboard Transporter berstatus online.
Repository berstatus attached dan accessible.
Backup VM serta recovery point lama dapat ditampilkan.
Self-healing selesai tanpa error.
Satu file atau VM dapat dipulihkan sebagai pengujian.
Satu backup job dapat dijalankan secara manual.
Satu replication job dapat dijalankan secara manual.
Schedule berjalan dari NAKIVO baru tanpa ada job aktif pada NAKIVO lama.
Kesimpulan
Dari pengujian ini, export dan import system configuration dapat memindahkan konfigurasi utama NAKIVO seperti inventory, credentials, job backup, job replikasi, dan schedule. Namun, proses tersebut tidak memindahkan data fisik pada Onboard Repository.
Data repository tetap harus disalin atau dipindahkan secara manual, kemudian path, Assigned Transporter, ownership, dan permission disesuaikan pada server baru. Hal penting yang saya temukan adalah permission folder NakivoBackup saja belum cukup; user bhsvc juga harus memiliki akses baca dan tulis pada direktori induk yang didaftarkan sebagai lokasi repository.
Saya ditugaskan untuk membuat cluster Proxmox VE yang terdiri dari dua node dan menggunakan Ceph sebagai shared storage. Setelah konfigurasi selesai, kemudian saya ditugaskan untuk melakukan pengujian dengan mematikan salah satu node untuk mengetahui kondisi VM, quorum Proxmox, dan quorum Ceph.
Eksperimen ini juga menguji solusi sementara berupa penghapusan Ceph Monitor pada pveceph2 dan penggunaan pvecm expected 1. Hasilnya menunjukkan bahwa quorum Proxmox/Corosync, quorum Ceph Monitor, dan redundansi data Ceph merupakan tiga hal berbeda yang harus ditangani secara terpisah.
Catatan: Konfigurasi dua node, satu Ceph Monitor, serta pool size 2/min_size 1 pada artikel ini digunakan untuk eksperimen. Konfigurasi tersebut bukan rekomendasi untuk lingkungan produksi.
Lingkungan Pengujian
Komponen
Konfigurasi
Proxmox VE
9.2.10
Kernel
7.0.14-12-pve
Ceph
Squid 19.2.5
Node 1
pveceph1
Node 2
pveceph2
OSD
3 OSD pada setiap node, total 6 OSD
Pool
pvecephpool
Replikasi pool
size 2, min_size 1
VM pengujian
Alpine Linux pada pveceph1 dengan disk di pvecephpool
Pada konfigurasi ini, size 2 membuat Ceph menyimpan dua salinan data. Sementara itu, min_size 1 mengizinkan I/O tetap berjalan ketika hanya tersedia satu salinan. Konfigurasi ini membantu pengujian dua node, tetapi meningkatkan risiko kehilangan data ketika penulisan berlangsung tanpa redundansi. Dokumentasi Proxmox Ceph juga memperingatkan bahwa replicated pool dengan min_size 1 dapat menyebabkan kehilangan data atau PG menjadi tidak lengkap jika salinan terakhir bermasalah.
1. Membuat Cluster Proxmox Dua Node
Pembuatan cluster dapat dilakukan melalui GUI Proxmox.
Membuat cluster pada pveceph1
Login ke GUI pveceph1.
Buka Datacenter → Cluster.
Klik Create Cluster.
Masukkan nama cluster.
Pilih jaringan Corosync yang akan digunakan pada bagian Cluster Network.
Klik Create.
Setelah cluster terbentuk, klik Join Information, lalu salin informasi yang ditampilkan.
Menggabungkan pveceph2
Login ke GUI pveceph2.
Buka Datacenter → Cluster.
Klik Join Cluster.
Tempel informasi dari pveceph1.
Masukkan password root milik pveceph1.
Pastikan alamat jaringan Corosync sudah sesuai.
Klik Join.
Node yang akan bergabung sebaiknya belum memiliki VM atau konfigurasi penting karena konfigurasi cluster pada node tersebut akan disesuaikan dengan cluster tujuan. Langkah GUI ini sesuai dengan panduan Proxmox VE Cluster Manager.
Periksa halaman Datacenter → Cluster setelah proses selesai. Pastikan pveceph1 dan pveceph2 terlihat berstatus online.
2. Menginstal dan Mengonfigurasi Ceph
Menginstal Ceph pada kedua node
Lakukan langkah berikut pada pveceph1 dan pveceph2:
Pilih nama node pada panel kiri.
Buka menu Ceph.
Klik Install Ceph atau ikuti wizard instalasi yang muncul.
Pilih Ceph Squid dan repository yang sesuai.
Selesaikan instalasi paket.
Pada node pertama, lanjutkan dengan inisialisasi konfigurasi Ceph. Tentukan Public Network dan Cluster Network sesuai jaringan yang sudah disiapkan. Node kedua menggunakan konfigurasi Ceph yang sudah tersimpan pada cluster, sehingga tidak perlu membuat cluster Ceph baru.
Periksa halaman konfigurasi Ceph.
Membuat Ceph Monitor
Pada konfigurasi awal eksperimen, MON dibuat pada kedua node:
Buka Ceph → Monitor.
Klik Create.
Pilih pveceph1, kemudian buat MON.
Ulangi untuk pveceph2.
Jika wizard konfigurasi sudah otomatis membuat MON pada pveceph1, cukup buat MON tambahan pada pveceph2.
Dengan dua MON, quorum membutuhkan keduanya aktif atau 2 dari 2 MON. Artinya, konfigurasi ini belum dapat menoleransi kegagalan satu MON. Ceph merekomendasikan sedikitnya tiga MON untuk produksi dan jumlah MON ganjil agar mayoritas tetap dapat terbentuk ketika satu MON gagal.
Periksa halaman Ceph → Monitor yang menampilkan MON pveceph1 dan pveceph2 dalam kondisi aktif serta berada dalam quorum.
Membuat enam OSD (Sesuaikan dengan kebutuhan)
Setiap node pada lab ini memiliki tiga disk khusus OSD.
Pilih node yang akan dikonfigurasi.
Buka Ceph → OSD.
Klik Create: OSD.
Pilih disk kosong yang akan digunakan.
Pastikan disk yang dipilih tidak berisi data penting.
Klik Create.
Ulangi hingga tersedia tiga OSD pada setiap node.
Peringatan: Pembuatan OSD akan menghapus isi disk yang dipilih. Periksa nama dan kapasitas disk sebelum menekan Create.
Periksa halaman Ceph → OSD atau tampilan CRUSH yang menunjukkan enam OSD berstatus up dan in, masing-masing tiga OSD di bawah pveceph1 dan pveceph2.
Membuat pool Ceph
Buka Ceph → Pools.
Klik Create.
Isi nama pool dengan pvecephpool.
Buat pool terlebih dahulu dengan Size3 dan Min. Size2.
Pilih CRUSH rule yang menempatkan replika pada host berbeda.
Aktifkan opsi penambahan storage jika tersedia, lalu klik Create.
Setelah pvecephpool berhasil dibuat, ubah konfigurasinya menjadi size 2/min_size 1:
Pilih pool pvecephpool, lalu klik Edit.
Ubah Size dari 3 menjadi 2.
Ubah Min. Size dari 2 menjadi 1.
Simpan perubahan.
Pilih pool internal .mgr, lalu klik Edit.
Ubah Size dan Min. Size pada .mgr menjadi 2 dan 1.
Simpan perubahan dan tunggu proses penyesuaian PG selesai.
Catatan: Pada eksperimen ini, konfigurasi 2/1 tidak langsung diterapkan ketika membuat pool. Pool dibuat lebih dahulu dengan nilai 3/2, kemudian pvecephpool dan pool internal .mgr diedit menjadi 2/1. Jika hanya pvecephpool yang diubah, .mgr masih menggunakan 3/2 dan Ceph dapat tetap menampilkan peringatan karena cluster hanya memiliki dua host OSD. Pool .mgr tidak perlu dihapus; cukup sesuaikan nilai replikasinya.
Jika pool belum muncul sebagai storage Proxmox, buka Datacenter → Storage → Add → RBD, lalu pilih pvecephpool sebagai pool. Aktifkan jenis konten Disk image sesuai kebutuhan.
3. Membuat VM Pengujian pada Ceph
Klik Create VM.
Tempatkan VM pada pveceph1.
Gunakan ISO Alpine Linux atau sistem operasi ringan lainnya.
Pada bagian disk, pilih pvecephpool sebagai storage.
Selesaikan instalasi, kemudian jalankan VM.
Pastikan status VM Running sebelum pengujian dimulai.
Sebelum mematikan node, pastikan status Ceph normal, kedua MON berada dalam quorum, dan seluruh OSD berstatus up serta in.
Periksa halaman Hardware VM yang menunjukkan disk berada di pvecephpool dan pastikan VM berstatus Running.
4. Pengujian Pertama: Mematikan pveceph2
Node kedua dimatikan langsung melalui GUI:
Pilih pveceph2 pada panel kiri.
Klik Shutdown.
Konfirmasi proses shutdown.
Tunggu hingga pveceph2 benar-benar tidak aktif.
Setelah itu, pemeriksaan dilakukan melalui GUI pveceph1.
Hasil pengujian
VM Alpine pada pveceph1 tetap berstatus Running.
MON pveceph2 tidak aktif sehingga dua MON tidak dapat membentuk mayoritas.
Tiga OSD milik pveceph2 menjadi down dan PG kehilangan satu salinan data.
Cluster Proxmox kehilangan quorum karena hanya tersedia satu dari dua vote Corosync.
Pembuatan VM baru tidak dapat dilakukan karena pmxcfs menjadi read-only ketika cluster Proxmox tidak quorate.
VM yang sudah berjalan dapat tetap aktif karena proses QEMU masih berjalan dan jalur data Ceph tidak selalu langsung berhenti ketika MON tidak memiliki quorum. Namun, kondisi tersebut tidak boleh dianggap sebagai jaminan ketersediaan. Perubahan peta cluster, koneksi baru, atau gangguan tambahan tetap dapat menyebabkan I/O berhenti.
VM tetap running (dapat di ping) namun tidak dapat diakses.
5. Menghapus MON pveceph2
Pengujian berikutnya bertujuan memastikan MON pada node yang mati tidak lagi menjadi bagian dari quorum Ceph. Sebelum menghapus MON, pveceph2 dinyalakan kembali dan ditunggu hingga cluster Proxmox serta Ceph kembali normal.
Jika GUI tidak dapat digunakan, perintah berikut dapat dijalankan melalui menu Shell pada pveceph2 ketika node masih aktif dan quorum tersedia:
pveceph mon destroy pveceph2
Pada eksperimen ini yang dihapus hanya service MON. OSD pada pveceph2 tetap dipertahankan sebagai bagian dari pool.
Mengulangi pengujian shutdown
Setelah MON pveceph2 berhasil dihapus, node tersebut kembali dimatikan melalui GUI. Hasilnya:
VM pada pveceph1 tetap Running.
MON tunggal pveceph1 dapat membentuk quorum 1 dari 1.
Error quorum MON yang sebelumnya terjadi tidak lagi menjadi penghambat.
Ceph tetap menampilkan kondisi degraded atau undersized karena tiga OSD pada pveceph2 tidak tersedia.
Cluster Proxmox tetap tidak quorate karena Corosync masih hanya memiliki satu dari dua vote.
Pembuatan VM atau perubahan konfigurasi tetap terblokir pada sisi Proxmox.
Penghapusan MON kedua hanya mengubah quorum Ceph. Langkah ini tidak memperbaiki quorum Proxmox dan tidak mengembalikan redundansi data Ceph.
Pengujian pembuatan VM gagal
6. Menggunakan pvecm expected 1 untuk Pengujian
Dalam pengujian ini, perintah berikut dijalankan melalui pveceph1 → Shell setelah dipastikan bahwa pveceph2 benar-benar mati:
pvecm expected 1
Perintah tersebut mengubah jumlah vote yang diharapkan menjadi satu sehingga pveceph1 kembali quorate. Setelah itu, pmxcfs dapat ditulis kembali dan pengujian melalui GUI dapat dilanjutkan. Pada lab ini, pembuatan VM baru digunakan hanya untuk membuktikan bahwa hambatan sebelumnya berasal dari quorum Proxmox.
Peringatan:pvecm expected 1 merupakan tindakan pemulihan sementara, bukan konfigurasi permanen untuk cluster dua node. Jalankan hanya setelah node lain dipastikan benar-benar mati atau sudah di-fence. Jangan menjalankannya pada dua sisi yang terpisah karena dapat menyebabkan split-brain dan perubahan konfigurasi yang saling bertentangan. Dokumentasi Proxmox menempatkan perintah ini sebagai workaround ketika quorum hilang dan memperingatkan agar perubahan yang memengaruhi cluster tidak dilakukan dalam kondisi vote dipaksa. Untuk produksi, QDevice direkomendasikan sebagai vote ketiga pada cluster dua node.
Ringkasan Hasil Pengujian
Kondisi
Quorum Proxmox
Quorum Ceph MON
Kondisi data Ceph
VM yang sudah berjalan
Perubahan konfigurasi/VM baru
Kedua node aktif, dua MON
Ada
2/2
Normal
Berjalan
Bisa
pveceph2 mati, dua MON masih terdaftar
Tidak ada
Tidak ada, hanya 1/2
Degraded, satu replika tersisa
Tetap berjalan pada pengujian
Tidak bisa
pveceph2 mati, MON-nya sudah dihapus
Tidak ada
Ada, 1/1
Degraded, satu replika tersisa
Tetap berjalan pada pengujian
Tidak bisa
Kondisi sebelumnya + pvecm expected 1
Ada secara paksa
Ada, 1/1
Tetap degraded
Tetap berjalan pada pengujian
Dapat diuji melalui GUI
Tabel tersebut menunjukkan bahwa MON Ceph dan quorum Corosync bekerja secara independen. Memperbaiki salah satunya tidak otomatis memperbaiki komponen lain.
Solusi Implementasi Dua Node
Menggunakan satu MON memang membuat Ceph memiliki quorum 1/1, tetapi seluruh cluster bergantung pada pveceph1. Jika MON tersebut mati, Ceph tidak memiliki MON lain untuk mengambil alih. Karena itu, konfigurasi ini hanya sesuai untuk membuktikan perilaku sistem dalam lab.
Untuk implementasi dua node yang mempertimbangkan biaya subscription Proxmox, rencana pengujian berikutnya adalah menambahkan satu VM atau server Linux independen. Perannya mirip witness, tetapi komponen yang digunakan berbeda untuk Proxmox dan Ceph.
1. QDevice untuk quorum Proxmox
Pada sisi Proxmox/Corosync, server independen menjalankan corosync-qnetd. Kedua node PVE kemudian menggunakan QDevice untuk memperoleh vote ketiga. Dengan demikian, satu node PVE yang masih aktif bersama QDevice dapat mempertahankan quorum. Proxmox secara resmi merekomendasikan QDevice untuk cluster dua node yang membutuhkan ketersediaan lebih baik pada panduan Proxmox VE Cluster Manager.
2. MON ketiga untuk quorum Ceph
Pada sisi Ceph tidak terdapat QDevice yang sama seperti Corosync. Solusinya adalah menjalankan Ceph Monitor ketiga pada server atau VM independen. Sebelum pengujian ini dilakukan, MON pveceph2 perlu dibuat kembali sehingga susunannya menjadi:
MON pveceph1;
MON pveceph2;
MON ketiga pada host independen.
Dengan tiga MON, Ceph dapat mempertahankan quorum ketika satu MON mati karena masih tersedia dua dari tiga MON. MON ketiga adalah MON penuh yang menyimpan cluster map dan ikut melakukan voting, bukan sekadar QDevice. Prinsip mayoritas dan rekomendasi minimal tiga MON dijelaskan pada dokumentasi Adding/Removing Monitors.
Jika MON ketiga ditempatkan pada VM, disk dan proses boot VM tersebut tidak boleh bergantung pada pvecephpool yang sedang dilindungi. VM harus berjalan pada host, storage, dan jalur daya yang independen agar tidak terjadi ketergantungan melingkar.
Untuk lab atau lingkungan dengan sumber daya terbatas, satu server independen dapat diuji untuk menjalankan corosync-qnetd dan Ceph MON ketiga. Keduanya tetap merupakan service berbeda dan harus diuji secara terpisah. Kompatibilitas versi Ceph, prosedur pemeliharaan, serta dukungan vendor perlu dipastikan sebelum digunakan pada produksi.
3. MON ketiga tidak menambah replika data
Penambahan MON ketiga hanya mempertahankan quorum monitor. Ketika pveceph2 mati, tiga OSD di node tersebut tetap hilang dan pool size 2/min_size 1 hanya dapat melanjutkan I/O dengan satu salinan data jika PG masih aktif. Ceph tetap dapat menampilkan HEALTH_WARN, degraded, atau undersized.
Jika dibutuhkan redundansi storage yang benar-benar dapat menoleransi kegagalan satu host tanpa berjalan pada satu salinan, diperlukan host OSD ketiga atau desain storage lain yang sesuai. Backup eksternal juga tetap wajib karena replikasi Ceph bukan pengganti backup.
Pertimbangan Biaya Subscription
Jika pada lingkungan produksi menggunakan subscription Proxmox, setiap server fisik Proxmox VE harus dicakup sesuai jumlah CPU socket yang digunakan, dan seluruh node dalam satu cluster menggunakan tingkat subscription yang sama. Karena itu, menambahkan node PVE ketiga dapat meningkatkan biaya subscription. Ketentuan ini dapat dilihat pada Proxmox Subscription FAQ.
Alternatif berupa server Linux independen yang hanya menjalankan QDevice dan Ceph MON dapat menghindari penambahan node PVE ketiga. Namun, desain ini menggunakan MON eksternal yang dikelola secara manual.
Rencana Pengujian Berikutnya
Sesuai arahan yang ditugaskan pada saya, pengujian selanjutnya berfokus pada penambahan Ceph MON di luar cluster PVE agar jumlah MON menjadi 3 dan min_size menjadi 2 dan quorum Ceph tetap tersedia ketika salah satu node PVE mati. Host eksternal akan berperan mirip QDevice, tetapi menjalankan Ceph MON penuh.
Topologi yang akan diuji:
Host
Cluster PVE
Service Ceph
pveceph1
Cluster pveceph
MON dan 3 OSD
pveceph2
Cluster pveceph
MON dan 3 OSD
PVE standalone atau Linux lain
Di luar cluster
MON eksternal tanpa OSD
Tahapan pengujiannya adalah sebagai berikut:
Menyiapkan PVE standalone atau server/VM Linux pada infrastruktur dan storage yang independen dari pvecephpool.
Memasang paket Ceph yang kompatibel dengan Ceph Squid 19.2.5 pada host eksternal.
Menyalakan pveceph2 dan membuat kembali MON pada node tersebut.
Menambahkan Ceph MON ketiga pada host eksternal.
Memastikan ketiga MON berstatus aktif dan membentuk quorum 3/2.
Kesimpulan
Pada eksperimen ini, VM di pveceph1 tetap berjalan ketika pveceph2 dimatikan, tetapi pembuatan VM baru terblokir karena cluster Proxmox kehilangan quorum. Menghapus MON pveceph2 membuat MON tunggal pveceph1 memiliki quorum 1/1, sedangkan pvecm expected 1 memungkinkan pengujian lanjutan pada sisi Proxmox.
Kedua tindakan tersebut hanya solusi sementara untuk lab. Desain dua node yang lebih tepat membutuhkan QDevice untuk quorum Proxmox dan MON ketiga pada host independen untuk quorum Ceph. Jika targetnya juga mempertahankan redundansi data ketika satu node mati, MON ketiga saja tidak cukup—dibutuhkan OSD pada host ketiga atau arsitektur storage lain yang sesuai.
Ceph umumnya menggunakan minimal tiga Monitor untuk menyediakan quorum dan redundansi. Namun, pada pengujian ini saya mencoba menjalankan cluster Proxmox VE dua node dengan hanya satu Ceph Monitor.
Tujuan pengujian ini adalah mengetahui kondisi VM dan storage Ceph ketika node kedua dimatikan, serta memastikan apakah VM baru masih dapat dibuat pada node yang tetap aktif.
Konfigurasi Homelab
Pengujian dilakukan menggunakan konfigurasi berikut:
Komponen
Konfigurasi
Proxmox VE
9.2.10
Ceph
19.2.5 Squid
Node pertama
pveceph1 – 192.168.14.57
Node kedua
pveceph2 – 192.168.14.58
Jumlah OSD
6 OSD
OSD pveceph1
osd.3, osd.4, dan osd.5
OSD pveceph2
osd.0, osd.1, dan osd.2
Storage VM
pvecephpool
Pool replica
size=2
Minimum replica
min_size=1
Ceph Monitor
Hanya di pveceph1
VM pengujian
Alpine Linux di pveceph1
Pada kondisi awal, kedua node aktif, enam OSD berstatus up/in, seluruh Placement Group berstatus active+clean, dan Ceph menunjukkan status HEALTH_OK.
Mengubah Ceph Menjadi Satu Monitor
Awalnya Ceph memiliki dua Monitor, yaitu:
pveceph1
pveceph2
Sebelum Monitor kedua dihapus, dilakukan pemeriksaan untuk memastikan bahwa mon.pveceph2 aman dikeluarkan dari monmap. Hasil pemeriksaan menunjukkan:
root@pveceph1:~# ceph mon ok-to-rm pveceph2
safe to remove mon.pveceph2
Monitor pveceph2 kemudian dihapus melalui Proxmox Web GUI dengan langkah berikut:
Pilih node pveceph2.
Buka menu Ceph → Monitor.
Pilih Monitor pveceph2.
Klik Destroy.
Konfirmasi penghapusan dan tunggu sampai proses selesai.
Alternatifnya, penghapusan Monitor dapat dilakukan melalui CLI pada node pveceph2:
pveceph mon destroy pveceph2
Proses tersebut hanya menghapus fungsi Ceph Monitor pada pveceph2. Node Proxmox, tiga OSD, dan layanan Ceph lainnya pada node tersebut tetap dipertahankan.
Setelah proses selesai, Ceph hanya memiliki satu Monitor aktif, yaitu pveceph1, dengan quorum 1/1.
Dokumentasi Ceph menjelaskan:
“A cluster will run fine with a single Monitor; however, a single Monitor is a single-point-of-failure.”
Artinya, satu Monitor tetap dapat melayani cluster Ceph. Namun, jika Monitor tersebut gagal, tidak ada Monitor lain yang dapat mengambil alih. Ceph Monitor Configuration Reference.
Membuat VM Pengujian
Selanjutnya, dibuat satu VM Alpine Linux dengan ketentuan berikut:
VM ditempatkan di node pveceph1.
Disk VM menggunakan storage pvecephpool.
VM tidak dimasukkan ke dalam konfigurasi Proxmox HA.
VM dinyalakan sebelum proses pengujian dimulai.
Melalui Web GUI, VM dipastikan telah berstatus Running dan disk-nya menggunakan storage Ceph.
Mematikan pveceph2
Setelah VM Alpine berjalan, node pveceph2 dimatikan melalui Proxmox Web GUI:
Pilih node pveceph2.
Klik tombol Shutdown.
Konfirmasi proses shutdown.
Tunggu sampai node benar-benar berstatus offline.
Setelah pveceph2 mati, pemeriksaan dilakukan melalui Web GUI pada pveceph1, meliputi:
Status VM Alpine pada halaman Summary.
Status node pada halaman Datacenter.
Status Ceph pada menu Ceph.
Status Monitor pada menu Ceph → Monitor.
Status OSD pada menu Ceph → OSD.
Status storage pvecephpool.
Percobaan membuat VM baru di pveceph1.
Hasil Pengujian
VM yang sudah berjalan tetap running
Setelah pveceph2 dimatikan, VM Alpine di pveceph1 tetap berstatus Running.
Hal ini terjadi karena:
Ceph Monitor pveceph1 tetap memiliki quorum 1/1.
Tiga OSD di pveceph1 masih aktif.
Pool menggunakan min_size=1.
Proses VM telah berjalan di pveceph1.
Meskipun VM tetap berjalan, Ceph berada dalam kondisi degraded karena tiga OSD pada pveceph2 sudah tidak tersedia.
Dengan size=2 dan min_size=1, Ceph masih dapat melayani I/O menggunakan satu replica yang tersedia. Namun, data pada kondisi tersebut hanya memiliki satu salinan aktif.
Dokumentasi Ceph memperingatkan bahwa penggunaan size=2 atau min_size=1 memiliki risiko kehilangan data dan tidak direkomendasikan sebagai konfigurasi normal untuk production. Dokumentasi Ceph Pool.
VM baru tidak dapat dibuat
Ketika dilakukan percobaan membuat VM baru di pveceph1, proses tersebut gagal walaupun storage Ceph masih dapat diakses.
Kegagalan ini bukan disebabkan oleh single Ceph Monitor, melainkan karena cluster Proxmox kehilangan quorum.
Cluster Proxmox masih mengharapkan dua vote, sedangkan setelah pveceph2 dimatikan hanya tersedia satu vote dari pveceph1. Akibatnya, Proxmox Cluster File System atau pmxcfs berubah menjadi read-only.
Dokumentasi Proxmox menjelaskan salah satu karakteristik pmxcfs sebagai berikut:
“Read-only when a node loses quorum.”
Karena konfigurasi VM disimpan di dalam /etc/pve, Proxmox tidak dapat menulis konfigurasi VM baru ketika cluster tidak memiliki quorum. Dokumentasi Proxmox pmxcfs.
Ringkasan Hasil
Pengujian
Hasil
Ceph Monitor pveceph2 dihapus
Berhasil
Ceph berjalan dengan satu Monitor
Berhasil, quorum 1/1
pveceph2 dimatikan
Berhasil
VM Alpine di pveceph1
Tetap running
Storage Ceph
Tetap tersedia, tetapi degraded
OSD pada pveceph2
Down
Membuat VM baru di pveceph1
Gagal
Penyebab kegagalan
PVE/Corosync kehilangan quorum
Pengujian Lanjutan
Untuk kebutuhan lab, jumlah expected vote dapat diubah sementara menjadi satu:
pvecm expected 1
Perintah tersebut dapat membuat pveceph1 kembali memiliki quorum sehingga pengujian pembuatan VM baru dapat dilanjutkan.
Namun, perintah ini hanya boleh digunakan setelah memastikan pveceph2 benar-benar mati, bukan sekadar terputus dari jaringan. Penggunaannya dalam kondisi node lain masih aktif dapat menimbulkan risiko split-brain.
Untuk cluster Proxmox dua node yang digunakan secara permanen, Proxmox merekomendasikan QDevice sebagai vote ketiga. Dokumentasi Proxmox Cluster Manager.
Kesimpulan
Pengujian menunjukkan bahwa satu Ceph Monitor di pveceph1 tetap dapat melayani storage ketika pveceph2 dimatikan. VM Alpine yang sudah berjalan tetap berstatus Running karena Ceph masih memiliki MON quorum 1/1 dan pool memperbolehkan I/O dengan satu replica.
Namun, VM baru tidak dapat dibuat karena cluster Proxmox kehilangan quorum dan pmxcfs berubah menjadi read-only. Dengan demikian, kegagalan pembuatan VM baru berasal dari quorum PVE/Corosync, bukan dari quorum Ceph.
Konfigurasi satu Ceph Monitor dan pool size=2/min_size=1 dapat digunakan untuk eksperimen, tetapi tidak direkomendasikan untuk production karena tidak memiliki redundansi Monitor dan hanya menyisakan satu salinan data ketika salah satu node mati.
NAKIVO dapat digunakan untuk membuat replica VM dari satu Proxmox ke Proxmox lainnya. Replica tersebut dapat dinyalakan ketika VM utama mengalami gangguan atau saat melakukan pengujian recovery.
Pada pengujian homelab ini, replication sempat gagal dan menghasilkan beberapa warning. Berikut konfigurasi yang saya lakukan agar prosesnya dapat berjalan dengan lancar.
Homelab yang Digunakan
Saya menggunakan dua server Proxmox dengan backend storage Ceph.
Komponen
Fungsi
pve-nakivo
Host VM sumber
pve-nakivo2
Host VM replica
Ceph RBD
Storage disk VM sumber dan replica
NAKIVO
Mengatur dan menjalankan proses replication
Alur replication-nya sebagai berikut:
VM sumber
pve-nakivo + Ceph
↓
NAKIVO
↓
VM replica
pve-nakivo2 + Ceph
NAKIVO berperan memproses dan memindahkan data. Hasil akhirnya tetap berupa VM replica pada pve-nakivo2, bukan disimpan di server NAKIVO.
Sebelum menjalankan replication, ada empat hal yang perlu diperiksa.
1. Ubah Lokasi Temporary Overlay
Untuk VM yang berada pada block storage seperti Ceph RBD, NAKIVO membuat temporary overlay pada host Proxmox. Secara default, file tersebut disimpan di /tmp.
Pada pengujian pertama, replication gagal dengan error:
Host has no free space for overlay files
Not enough space for creation of temporary overlay file in "/tmp" location.
Periksa kapasitas /tmp pada pve-nakivo:
df -hT /tmp
findmnt -T /tmp
Pada homelab saya, /tmp menggunakan tmpfs dengan kapasitas 2 GB. Karena tidak cukup, saya membuat lokasi temporary baru pada filesystem root yang sudah memiliki ruang lebih besar:
Simpan konfigurasi lalu lakukan Refresh Inventory.
Untuk homelab, direktori tersebut cukup digunakan selama kapasitas root dipantau. Pada production, sebaiknya gunakan filesystem terpisah agar temporary overlay tidak memenuhi root Proxmox.
2. Pastikan VM Sumber Menyala
Pada pengujian berikutnya, replication VM yang sedang off dapat diproses oleh NAKIVO, tetapi menghasilkan warning karena VM dijalankan dalam temporary prelaunch state.
Untuk mendapatkan hasil job yang bersih, saya memastikan VM sumber sudah menyala sebelum replication dimulai:
qm list
qm start <VMID>
Pastikan status VM pada pve-nakivo menunjukkan running.
3. Pasang dan Aktifkan QEMU Guest Agent
QEMU Guest Agent membantu Proxmox berkomunikasi dengan guest OS. NAKIVO membutuhkannya untuk melakukan guest OS quiescing agar filesystem berada dalam kondisi konsisten saat snapshot dibuat.
Tanpa agent, job dapat tetap berjalan tergantung konfigurasinya. Namun, dapat muncul warning karena quiesced snapshot tidak berhasil dibuat.
Jika agent baru diaktifkan tetapi belum terdeteksi, lakukan shutdown lalu start kembali VM. Uji komunikasinya dari host Proxmox:
qm agent <VMID> ping
Jika perintah tidak menghasilkan error, QEMU Guest Agent sudah terhubung.
4. Pisahkan Jadwal Backup dan Replication
Backup dan replication sebaiknya tidak dijalankan pada waktu yang sama. Keduanya menggunakan VM sumber, storage Ceph, jaringan, dan NAKIVO Transporter.
Pada homelab ini, jadwalnya dipisahkan seperti berikut:
Job
Contoh Jadwal
Backup
21.00 WIB
Replication
23.00 WIB
Berikan jeda sesuai durasi backup ditambah buffer. Pilihan yang lebih aman adalah menggunakan Run after another job, sehingga replication baru berjalan setelah backup selesai.
Periksa juga menu Calendar pada NAKIVO untuk memastikan tidak ada jadwal yang saling tumpang tindih.
Verifikasi Hasil Replication
Setelah konfigurasi diperbaiki, jalankan kembali job dan pastikan:
Job replication berstatus Successful tanpa error atau warning.
VM replica muncul pada pve-nakivo2.
Disk replica berada pada storage Ceph tujuan.
Temporary overlay dibersihkan setelah job selesai.
Penggunaan temporary storage dapat dipantau selama job berjalan:
watch -n 5 'df -h /var/lib/nakivo-temp; du -sh /var/lib/nakivo-temp 2>/dev/null'
Penutup
Replication NAKIVO pada Proxmox dapat berjalan lancar setelah lokasi temporary overlay memiliki ruang yang cukup, VM sumber dalam kondisi menyala, QEMU Guest Agent aktif, dan jadwal job tidak saling bertabrakan.
Empat pemeriksaan tersebut cukup sederhana, tetapi penting dilakukan sebelum replication diterapkan pada VM lainnya.
Saat melakukan pengujian replication NAKIVO pada Proxmox dengan backend storage Ceph, job gagal karena NAKIVO tidak memiliki ruang yang cukup untuk membuat temporary overlay. Masalah ini terjadi walaupun kapasitas Ceph masih tersedia.
Artikel ini membahas penyebabnya, proses pemeriksaan, dan solusi yang digunakan pada lab.
Kondisi Lab
Komponen
Konfigurasi
Proxmox
pve-nakivo.local
IP Proxmox
192.168.14.45
Disk OS awal
30 GB, ext4 dan LVM
Backend storage VM
Ceph
Ceph OSD
3 × 50 GB
VM pengujian
test1
VM sumber berada di Ceph, sedangkan replication dijalankan melalui NAKIVO.
Pesan Error
Pada replication pertama, NAKIVO menampilkan error berikut:
ReplicationDataCopy: Host has no free space for overlay files
Not enough space for creation of temporary overlay file in "/tmp" location.
Please make sure there is sufficient free space in the specified location.
Error tersebut menunjukkan bahwa masalah berada pada temporary file location di host Proxmox, bukan pada kapasitas Ceph.
Memahami Alur Replication NAKIVO
Pada storage berbasis block seperti Ceph RBD, NAKIVO membutuhkan overlay sementara selama pemrosesan VM.
VM test1 di Ceph
→ temporary overlay di host Proxmox
→ data diproses oleh NAKIVO
→ VM replica dibuat pada storage tujuan
→ temporary overlay dibersihkan
Jadi, /tmp bukan lokasi akhir replica. Hasil replication tetap berupa VM pada Proxmox dan storage tujuan yang dipilih dalam job.
Penyebab
Pada Proxmox VE 9, /tmp menggunakan tmpfs. Artinya, kapasitas /tmp berasal dari memory dan swap, bukan dari filesystem root.
Karena itu, memperbesar disk OS dan pve-root tidak otomatis menambah kapasitas /tmp. Root sudah memiliki ruang kosong 97 GB, tetapi NAKIVO masih menggunakan /tmp yang hanya 2 GB.
Memperbesar tmpfs juga bukan pilihan yang digunakan pada pengujian ini karena akan menambah batas penggunaan memory atau swap. Solusinya adalah membuat direktori temporary NAKIVO pada filesystem ext4 yang sudah diperbesar.
Simpan perubahan, kemudian lakukan Refresh Inventory.
Menjalankan Ulang Replication
Jalankan kembali replication job melalui NAKIVO. Selama proses berlangsung, kapasitas dan penggunaan direktori temporary dapat dipantau dengan:
watch -n 5 'df -h /var/lib/nakivo-temp; du -sh /var/lib/nakivo-temp 2>/dev/null'
Hasil yang diharapkan:
Job replication berstatus Successful.
VM replica muncul pada Proxmox.
Disk replica berada pada storage tujuan yang dipilih.
Temporary overlay dibersihkan setelah job selesai.
VM sumber tetap berjalan normal.
Catatan Penting
Penggunaan /var/lib/nakivo-temp sesuai untuk pengujian lab karena root sudah memiliki ruang yang cukup. Namun, direktori tersebut masih berada pada root volume Proxmox.
Untuk production atau VM dengan perubahan data tinggi, gunakan disk atau filesystem terpisah sebagai temporary file location. Tujuannya agar pertumbuhan overlay tidak memenuhi root dan mengganggu service Proxmox.
Selain itu, replication ke node dan Ceph yang sama hanya membuktikan fungsi replication. Skenario tersebut belum memberikan perlindungan disaster recovery karena VM sumber dan replica tetap bergantung pada host yang sama.
Kesimpulan
Replication gagal bukan karena Ceph kehabisan ruang, tetapi karena /tmp pada Proxmox hanya berupa tmpfs 2 GB. Memperbesar disk OS tidak menambah kapasitas /tmp secara otomatis.
Solusi pada lab ini adalah membuat /var/lib/nakivo-temp, kemudian mengarahkannya sebagai Temporary file location pada inventory NAKIVO. Dengan begitu, overlay dapat memakai ruang kosong filesystem ext4 tanpa bergantung pada tmpfs.
Selama ini Proxmox VE identik dengan server berbasis x86-64, seperti Intel dan AMD. Namun pada 5 Agustus 2026, Proxmox resmi merilis Proxmox VE untuk ARM64. Ini bukan lagi sekadar port komunitas atau eksperimen, tetapi sudah menjadi arsitektur resmi Proxmox VE.
Lalu, apa yang membuat ARM64 menarik untuk sebuah homelab?
ARM64 Itu Apa?
Secara sederhana, ARM64 adalah arsitektur prosesor yang berbeda dari x86-64.
Kita banyak menemukan ARM pada perangkat seperti:
Raspberry Pi
Single Board Computer
Apple Silicon
Ampere Server
NVIDIA Grace
Berbagai server hemat daya
ARM terkenal menarik untuk perangkat yang membutuhkan efisiensi daya tinggi.
Sebelumnya kita bisa menjalankan berbagai workload langsung pada Linux ARM, tetapi jika ingin pengalaman virtualisasi seperti Proxmox, dukungannya tidak semudah pada Intel atau AMD.
Sekarang Proxmox mulai mengubah kondisi tersebut.
1. Proxmox Bisa Berjalan pada Hardware yang Lebih Hemat Daya
Menurut saya, ini adalah kelebihan paling menarik untuk homelab.
Banyak homelab berjalan 24 jam setiap hari, padahal workload yang dijalankan belum tentu membutuhkan server dengan konsumsi daya besar.
ARM membuka kemungkinan membangun node Proxmox untuk workload ringan seperti:
DNS Server
Monitoring
Home Automation
Git Server
CI/CD Runner
Kubernetes Node
Container
Development Environment
Artikel Virtualization Howto juga menyoroti ARM64 sebagai platform yang menarik untuk layanan always-on, terutama ketika tujuan homelab adalah menjalankan banyak service dengan konsumsi daya sekecil mungkin.
Artinya konsepnya bisa seperti:
Proxmox ARM64
│
├── LXC DNS
├── LXC Monitoring
├── VM Kubernetes
├── VM Git Server
└── LXC Home Automation
Satu perangkat ARM kecil bisa menjadi host untuk beberapa service sekaligus.
2. Bukan Proxmox Versi “Lite”
Hal menarik lainnya adalah Proxmox ARM64 bukan versi Proxmox yang fiturnya banyak dipangkas.
Proxmox menyatakan ARM64 memiliki feature parity untuk komponen utama seperti:
KVM
LXC
Networking
Clustering
High Availability
ZFS
Ceph
Backup
Web Management
Jadi pengalaman administrasinya pada dasarnya tetap seperti Proxmox yang biasa kita gunakan pada Intel atau AMD.
Ini penting karena kita tidak perlu mempelajari platform virtualisasi baru hanya karena menggunakan CPU ARM.
3. ZFS dan Ceph Tetap Tersedia
Ini mungkin salah satu bagian paling menarik.
Proxmox tidak hanya membawa kemampuan menjalankan VM dan container ke ARM64, tetapi juga melakukan validasi pada ZFS dan Ceph.
Artinya secara arsitektur kita tetap bisa membangun environment seperti:
atau menggunakan ZFS sebagai local storage seperti pada deployment Proxmox biasa.
Untuk homelab, mungkin Ceph ARM64 masih cukup berlebihan. Tetapi keberadaan fitur tersebut menunjukkan bahwa Proxmox ARM64 bukan sekadar proyek untuk menjalankan VM pada sebuah SBC.
4. Homelab Bisa Menjadi Lebih Kecil
ARM juga menarik karena banyak tersedia dalam bentuk perangkat yang sangat compact.
Bayangkan dibanding menggunakan beberapa server besar:
Rack Server
Rack Server
Rack Server
kita berpotensi memiliki:
ARM Node
ARM Node
ARM Node
dengan ukuran yang jauh lebih kecil.
Ini cocok dengan tren homelab sekarang yang mulai banyak menggunakan:
Mini PC
Mini rack
SBC
Low-power server
Tujuannya bukan mengejar performa maksimal, tetapi mencari titik seimbang antara:
Performance + Power Consumption + Size + Cost
Apakah Bisa Menggunakan Raspberry Pi?
Di sinilah ada hal yang perlu diperhatikan.
ARM64 support tidak berarti Raspberry Pi resmi didukung Proxmox.
Dukungan resmi Proxmox saat ini ditujukan pada hardware ARM yang menggunakan:
UEFI
ACPI
NVIDIA Grace Hopper dan NVIDIA Vera menjadi platform yang mendapatkan dukungan resmi sejak rilis awal. Hardware ARM lain berbasis UEFI ARMv9-A, serta umumnya ARMv8-A, berada pada kategori best-effort support.
Sedangkan Raspberry Pi secara resmi belum termasuk platform yang didukung karena karakteristik boot dan hardware discovery-nya. Meski demikian, pengguna komunitas sudah melaporkan keberhasilan menjalankan Proxmox VE ARM64 pada Raspberry Pi 5.
Jadi bedakan antara:
Hardware
Status
NVIDIA Grace / Vera
Officially Supported
UEFI ARM Server
Best Effort
Raspberry Pi
Tidak resmi didukung
Artinya Raspberry Pi lebih cocok untuk eksperimen, bukan deployment yang membutuhkan support resmi.
ARM64 Belum Menggantikan x86
Ini juga penting.
ARM64 tidak otomatis membuat Intel dan AMD menjadi tidak relevan.
Untuk kompatibilitas software, x86-64 masih menjadi pilihan paling aman.
Terutama jika kita membutuhkan:
Windows VM
Software legacy
Commercial application
Appliance yang hanya menyediakan image x86
Driver tertentu
Selain itu, VM ARM hanya dapat berjalan pada node ARM dan VM x86 hanya dapat berjalan pada node x86. Live Migration juga hanya dapat dilakukan antar-node dengan arsitektur yang sama. Mixed ARM64/x86 cluster secara teknis tidak diblokir, tetapi belum menjadi konfigurasi yang resmi didukung.
Jadi jangan menganggap:
VM x86
↓
Live Migration
↓
ARM64
Hal tersebut tidak bisa dilakukan begitu saja.
Jadi Apa Kelebihan Proxmox ARM64?
Jika diringkas:
Kelebihan
Manfaat untuk Homelab
Efisiensi daya
Cocok untuk server 24/7
Hardware compact
Homelab lebih kecil
Proxmox full feature
Tetap dapat KVM, LXC, cluster, HA
ZFS & Ceph
Storage tetap fleksibel
ARM ecosystem
Banyak pilihan hardware baru
Virtualisasi ARM
Cocok untuk Kubernetes dan Linux
Management sama
Tidak perlu belajar hypervisor baru
Menurut saya bukan berarti kita harus mengganti seluruh homelab menjadi ARM.
Yang lebih menarik justru menggabungkannya dengan x86.
Contohnya:
HOMELAB
│
┌────────┴────────┐
│ │
ARM64 x86-64
│ │
DNS / Git / Windows VM
Monitoring Legacy Apps
Kubernetes Heavy Workload
Containers General VM
ARM digunakan untuk workload ringan dan always-on, sedangkan Intel atau AMD tetap digunakan ketika membutuhkan kompatibilitas dan performa yang lebih luas.
Kesimpulan
Hadirnya Proxmox ARM64 menarik bukan hanya karena sekarang Proxmox bisa berjalan pada prosesor ARM.
Yang lebih penting adalah kita mendapatkan pengalaman Proxmox yang hampir sama pada arsitektur yang membuka peluang server lebih kecil dan hemat daya.
Untuk homelab, ini membuat berbagai eksperimen seperti Kubernetes, container, monitoring, DNS, Git server, dan development environment semakin menarik untuk dijalankan pada node ARM yang aktif 24/7.
Namun ARM64 belum sepenuhnya menggantikan x86.
Untuk saat ini saya melihatnya lebih cocok sebagai tambahan untuk homelab, bukan pengganti seluruh node Intel atau AMD.
Dan justru di situlah bagian menariknya: kita sekarang punya pilihan arsitektur yang lebih luas ketika membangun Proxmox homelab.
Referensi
Proxmox ARM64 Changes Everything for Home Labs Brandon Lee — Virtualization Howto 6 Agustus 2026
Proxmox Virtual Environment launches official Arm64 Support Proxmox Server Solutions 5 Agustus 2026
Pada artikel sebelumnya, saya sudah menyiapkan seluruh kebutuhan Terraform untuk Proxmox, mulai dari Terraform Controller, API Token, konfigurasi network, hingga file Terraform untuk membuat tiga VM Ubuntu.
Kali ini saya akan mengaplikasikan konfigurasi yang sudah dibuat tersebut dan melihat hasil deployment-nya langsung di homelab.
Topologi homelab
Seluruh perangkat berada pada network 192.168.14.0/24.
Saya menggunakan provider bpg/proxmox sebagai penghubung antara Terraform dengan Proxmox API.
Secara sederhana, Terraform tidak membuat VM dengan mengklik Web UI. Terraform mengirim request ke API Proxmox menggunakan API Token yang sudah dibuat.
Konfigurasi Terraform
│
▼
bpg/proxmox Provider
│
│ API Request
▼
Proxmox API :8006
│
▼
Resource dibuat di Proxmox
API tersebut memungkinkan Terraform untuk mengunduh image, membuat VM, mengatur disk, network, Cloud-init, hingga menyalakan VM.
Terraform kemudian menjalankan beberapa proses secara otomatis:
Mengunduh Ubuntu 24.04 Cloud Image.
Mengimport image ke storage Proxmox.
Membuat tiga VM.
Membuat disk dari Ubuntu Cloud Image.
Mengatur CPU, RAM, disk, dan network.
Mengatur IP statis melalui Cloud-init.
Memasukkan SSH public key.
Menyalakan seluruh VM.
Dengan cara ini, saya tidak perlu menulis resource VM sebanyak tiga kali. Terraform melakukan iterasi berdasarkan hostname, VM ID, dan IP yang sudah ditentukan.
Menjalankan Plan yang Sudah Disimpan
Pada artikel panduan sebelumnya, konfigurasi sudah diperiksa menggunakan:
terraform init
terraform validate
Kemudian rencana deployment dibuat dan disimpan ke file tfplan:
terraform plan -out=tfplan
Hasil plan menunjukkan:
Plan: 4 to add, 0 to change, 0 to destroy.
Empat resource tersebut terdiri dari:
Resource
Jumlah
Ubuntu Cloud Image
1
VM Ubuntu
3
Untuk menjalankan rencana yang sudah disimpan tersebut, saya cukup menjalankan:
terraform apply tfplan
Dengan menggunakan saved plan, Terraform menerapkan perubahan yang sebelumnya sudah diperiksa pada saat terraform plan.
Hasil Deployment
Setelah proses selesai, Terraform berhasil membuat ketiga VM sesuai konfigurasi.
State digunakan Terraform untuk mencatat resource yang dikelolanya. Karena itu, konfigurasi yang sama nantinya dapat digunakan untuk menambah, mengubah, atau menghapus VM.
Kesimpulan
Percobaan ini berhasil membuat 3 VM Ubuntu di Proxmox secara otomatis menggunakan Terraform.
Rancang dan konfigurasi
↓
terraform plan -out=tfplan
↓
terraform apply tfplan
↓
3 VM Ubuntu Running
Jika sebelumnya pembuatan VM dilakukan satu per satu melalui Web UI, sekarang konfigurasi infrastrukturnya sudah tersimpan sebagai kode dan dapat digunakan kembali.
Percobaan ini juga menjadi dasar sebelum melanjutkan otomatisasi berikutnya menggunakan Ansible untuk melakukan konfigurasi sistem setelah VM selesai dibuat.
Pada artikel sebelumnya saya membahas gambaran otomatisasi homelab Proxmox menggunakan Terraform dan Ansible.
Kali ini saya mulai mempraktikkannya di homelab, dimulai dari Terraform terlebih dahulu. Targetnya adalah menyiapkan Terraform Controller yang nantinya dapat membuat 3 VM Ubuntu secara otomatis di Proxmox.
Pada bagian ini proses hanya sampai terraform plan, sehingga belum ada perubahan yang diterapkan ke Proxmox.
Rancangan Homelab
Seluruh server menggunakan network 192.168.14.0/24.
output "deployed_vms" {
value = {
for name, vm in local.ubuntu_vms : name => {
vm_id = vm.vm_id
ip = split("/", vm.ip)[0]
ssh = "ssh ubuntu@${split("/", vm.ip)[0]}"
}
}
}
Output ini nantinya menampilkan informasi VM setelah deployment dilakukan.
13. Inisialisasi dan Validasi Terraform
Rapikan konfigurasi:
terraform fmt
Download dan inisialisasi provider:
terraform init
Kemudian lakukan validasi:
terraform validate
Jika konfigurasi benar:
Success! The configuration is valid.
Sampai tahap ini Terraform sudah siap berkomunikasi dengan Proxmox dan konfigurasi VM sudah berhasil divalidasi.
14. Melihat Terraform Plan
Sebelum benar-benar membuat VM, periksa terlebih dahulu perubahan yang akan dilakukan Terraform.
Pastikan API token masih tersedia:
echo "${PROXMOX_VE_API_TOKEN:+API token sudah tersedia}"
Kemudian:
terraform plan
Targetnya Terraform menampilkan:
Plan: 4 to add, 0 to change, 0 to destroy.
Empat resource tersebut adalah:
Resource
Jumlah
Ubuntu Cloud Image
1
Ubuntu VM
3
Total
4
Plan juga dapat disimpan:
terraform plan -out=tfplan
File tfplan inilah yang nantinya dapat diterapkan menggunakan terraform apply.
Saat mencari bahan bacaan seputar Proxmox, saya menemukan halaman Mr.PlanB yang membahas berbagai teknologi storage. Dari sana, saya menyadari bahwa memilih storage sebaiknya tidak dimulai dari pertanyaan “Teknologi mana yang paling bagus?”, tetapi dari “Storage ini akan digunakan untuk kebutuhan apa?”
Proxmox VE mendukung storage lokal maupun shared storage. VM dan container dapat ditempatkan pada directory, LVM-thin, ZFS, NFS, iSCSI, hingga Ceph. Banyaknya pilihan tersebut bukan berarti kita harus menggunakan semuanya. Kita cukup memilih arsitektur yang sesuai dengan jumlah node, workload, performa, dan kebutuhan ketersediaan layanan.
Mulai dari kebutuhan
Pada fitur storage picker milik Mr.PlanB, pemilihan storage dimulai dari tiga pertanyaan:
Berapa jumlah node yang digunakan?
Apa platform utamanya?
Apa prioritas utama storage tersebut?
Prioritasnya dibagi menjadi integritas data, kemudahan penggunaan, scalability dan high availability, serta backup dan archive. Kebutuhan performa, kapasitas, dan redundancy juga tetap menjadi pertimbangan.
Untuk lingkungan Proxmox, variabel tersebut dapat disederhanakan menjadi:
Pertimbangan
Variabel
Jumlah node
Single node, cluster kecil, atau cluster besar.
Jenis workload
VM pengujian, file server, database, atau layanan production.
Availability
Layanan harus tetap berjalan saat node gagal.
Performa
Apakah workload membutuhkan IOPS atau throughput tinggi.
Pengelolaan
Seberapa kompleks storage yang mampu kita rawat.
Backup
Bagaimana data dipulihkan ketika VM terhapus atau rusak.
1. Storage lokal untuk single node
Untuk Proxmox single node, storage lokal biasanya sudah mencukupi.
Pilihan yang dapat digunakan antara lain:
Directory untuk ISO, template, backup, dan disk VM
LVM-thin untuk disk VM dan container
ZFS untuk snapshot, compression, checksum, dan integritas data
Directory dan LVM-thin cocok untuk memulai homelab karena konfigurasinya sederhana. Sementara itu, ZFS menarik ketika kita ingin mempelajari pengelolaan pool, snapshot, compression, serta perlindungan data berbasis checksum.
Mr.PlanB menempatkan ZFS sebagai pilihan yang kuat untuk integritas data dan menyebutnya sebagai fondasi yang banyak digunakan pada homelab Proxmox maupun TrueNAS.
Contoh penggunaan:
Satu server Proxmox untuk belajar
Beberapa VM dan container internal
Media server atau server pengujian
Workload yang tidak membutuhkan failover otomatis
2. Cluster kecil: storage lokal atau shared NAS
Ketika menggunakan dua atau tiga node Proxmox, kita memiliki beberapa pilihan.
ZFS Replication
Setiap node menggunakan storage ZFS lokal, kemudian disk VM direplikasi ke node lain berdasarkan jadwal.
Kelebihannya:
Arsitektur lebih sederhana
Tidak membutuhkan shared storage
Cocok untuk cluster kecil
Mengurangi waktu migrasi karena salinan disk sudah tersedia pada node tujuan
Namun, replication berjalan secara asynchronous. Jika node gagal sebelum proses replication berikutnya selesai, perubahan terbaru masih mungkin hilang.
NFS atau iSCSI
Kita juga dapat menggunakan NAS atau SAN sebagai shared storage:
NFS menyediakan file storage melalui jaringan dan relatif mudah dikelola.
iSCSI menyediakan block storage melalui jaringan dan umum digunakan untuk virtualisasi.
Shared storage memungkinkan beberapa node mengakses storage yang sama. Namun, server NAS, SAN, dan jaringan storage harus dirancang dengan baik agar tidak menjadi titik kegagalan tunggal. Proxmox secara resmi mendukung VM pada shared storage seperti NFS dan iSCSI.
Contoh penggunaan:
Homelab tiga node dengan NAS terpisah
Cluster kantor kecil
Infrastruktur yang sudah memiliki NAS atau SAN
3. Scale dan High Availability dengan Ceph
Untuk cluster production dengan beberapa node, kebutuhan storage biasanya tidak lagi hanya soal kapasitas. Storage juga harus tetap tersedia ketika disk atau node mengalami kegagalan.
Di sinilah Ceph dapat dipertimbangkan.
Ceph merupakan distributed storage yang menyediakan block, object, dan file storage. Data didistribusikan ke beberapa node sehingga storage dapat berkembang secara horizontal dan melakukan pemulihan ketika terjadi kegagalan.
Pada Proxmox, Ceph cocok ketika kita membutuhkan:
Shared storage terdistribusi
High availability
Live migration yang cepat
Penambahan kapasitas melalui node baru
Tidak bergantung pada satu server NAS
Namun, Ceph membutuhkan lebih banyak node, disk, jaringan cepat, monitoring, dan kemampuan troubleshooting. Untuk homelab kecil, ZFS Replication sering lebih mudah dirawat. Artikel komunitas Mr.PlanB menggambarkan ZFS sebagai pilihan praktis untuk cluster kecil, sedangkan Ceph lebih sesuai ketika kebutuhan scale dan HA memang sebanding dengan kompleksitasnya.
4. Backup tetap menggunakan PBS
Apa pun storage utama yang dipilih, kita tetap membutuhkan backup.
Untuk Proxmox, pilihan yang paling sesuai adalah Proxmox Backup Server karena terintegrasi langsung dengan Proxmox VE dan mendukung backup VM, container, serta physical host.
PBS menyediakan:
Incremental backup
Deduplication
Compression
Verifikasi integritas
Client-side encryption
Sinkronisasi datastore ke lokasi lain
Backup dikirim secara incremental dan dideduplicasi pada server sehingga penggunaan storage dan jaringan dapat ditekan.
Replication, RAID, ZFS, dan Ceph tidak menggantikan backup. Data yang terhapus, rusak, atau terkena kesalahan konfigurasi tetap memerlukan recovery point yang terpisah.
Rangkuman pilihan untuk Proxmox
Skenario
Pilihan awal
Homelab single node
Directory, LVM-thin, atau ZFS
Homelab dengan fokus integritas data
ZFS
Cluster kecil 2–3 node
ZFS Replication atau shared NFS
Sudah memiliki NAS/SAN
NFS atau iSCSI
Production multi-node dengan HA
Ceph
Backup VM dan container
Proxmox Backup Server
Backup di lokasi lain
PBS Remote dan Sync Job
Platform lain tentu memiliki pendekatan berbeda. Kubernetes, misalnya, dapat menggunakan Longhorn atau Rook-Ceph, sedangkan bare metal dan NAS dapat menggunakan ZFS, Unraid, NFS, atau iSCSI. Namun, untuk lingkungan Proxmox, pilihan umumnya tetap berputar pada storage lokal, shared storage, distributed storage, dan backup terpisah.
Kesimpulan
Tidak ada satu storage yang terbaik untuk semua kondisi.
Untuk homelab, pilihan sederhana seperti LVM-thin, ZFS, NFS, atau ZFS Replication sering sudah mencukupi. Pada skala production, kebutuhan shared storage, high availability, performa, redundancy, dan kemampuan recovery menjadi lebih penting sehingga NFS, iSCSI, atau Ceph dapat dipertimbangkan.
Menurut saya, storage terbaik bukan storage dengan teknologi paling rumit, tetapi storage yang sesuai dengan workload dan masih dapat kita kelola dengan baik.
Mulailah dari kebutuhan, ukur kemampuan hardware dan jaringan, kemudian pastikan seluruh VM dan container tetap memiliki backup terpisah di Proxmox Backup Server.
