Author: Rafi Harlianto

Replikasi NAKIVO Kembali Full Setelah VM Proxmox dengan Storage CEPH di Reboot
Dalam pengujian NAKIVO Backup & Replication, saya menemukan bahwa replikasi VM Proxmox kembali menjadi full setelah VM sempat reboot. Kondisi ini berkaitan dengan Change Block Tracking (CBT) dan format disk yang digunakan.

Homelab yang Digunakan

Pengujian menggunakan dua node Proxmox:
- pve-nakivo sebagai source
- pve-nakivo2 sebagai destination
- Ceph RBD sebagai backend storage
- VM test1 sebagai objek replikasi
Replikasi dijalankan dari pve-nakivo menuju pve-nakivo2 melalui schedule NAKIVO.

Hasil Pengujian

Pengujian dilakukan dengan urutan berikut:
1. Replikasi pertama dijalankan saat VM menyala.
2. NAKIVO menjalankan full replication.
3. VM kemudian di-reboot.
4. Schedule replikasi berikutnya kembali berjalan.
5. Replikasi kedua juga dijalankan secara full.
Pada job kedua, muncul warning:

Proxmox VE CBT data was not provided for the “test1” VM.

Kemudian NAKIVO menampilkan informasi:

Cannot perform incremental replication of the “test1” VM.

Artinya, schedule replikasi tetap berjalan. Namun, NAKIVO tidak dapat melanjutkan incremental replication karena informasi perubahan disk sebelumnya tidak tersedia.

Penyebabnya

CBT digunakan untuk mencatat blok disk yang berubah sejak replikasi terakhir. Dengan informasi tersebut, NAKIVO hanya perlu mengirimkan data yang berubah.

Menurut dokumentasi NAKIVO:
- Disk format QEMU/QCOW2 memiliki dirty bitmap yang persistent.
- Disk format RAW atau VMDK menggunakan dirty bitmap non-persistent.
- Reboot VM dengan disk RAW akan me-reset dirty bitmap.
Pada homelab ini, disk VM disimpan pada Ceph RBD. Ceph RBD merupakan block-level storage dan VM disk menggunakan format RAW. Ketika VM reboot, data CBT di-reset sehingga NAKIVO tidak mendapatkan informasi perubahan blok yang valid.

NAKIVO kemudian mencoba menggunakan proprietary change tracking. Namun, karena informasi increment sebelumnya tidak ditemukan, NAKIVO menjalankan full replication kembali.

Pengujian Lanjutan

Untuk memastikan incremental replication berjalan normal, pengujian dapat dilanjutkan dengan skenario berikut:
1. Jalankan full replication.
2. Tambahkan data pada VM tanpa melakukan reboot.
3. Tunggu schedule berikutnya.
4. Pastikan job berjalan secara incremental.
5. Reboot VM dan tunggu schedule selanjutnya.
6. Bandingkan hasil replikasi setelah reboot.
Untuk VM yang sering reboot, opsi Use proprietary method dapat digunakan pada pengaturan Change Tracking. Metode ini tidak bergantung sepenuhnya pada native CBT Proxmox, tetapi prosesnya lebih lama karena NAKIVO perlu membaca seluruh disk untuk mencari blok yang berubah.

QEMU Guest Agent tetap perlu dipasang untuk proses snapshot dan quiescing guest OS, tetapi tidak dapat mencegah CBT ter-reset setelah VM reboot.

Kesimpulan

Schedule replikasi tetap berjalan meskipun VM sempat reboot. Namun, pada VM yang menggunakan Ceph RBD dengan format RAW, reboot dapat me-reset CBT sehingga incremental replication tidak dapat dilanjutkan dan NAKIVO kembali menjalankan full replication.

Kondisi ini merupakan limitasi native CBT pada disk RAW, bukan kegagalan schedule replikasi.

Referensi
- Proxmox VE VM Did Not Provide Valid CBT Data – NAKIVO
- Storage: RBD – Proxmox VE
August 14, 2026
Menghindari Error dan Warning saat Replikasi NAKIVO di Proxmox
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:
```
mkdir -p /var/lib/nakivo-temp
chown root:root /var/lib/nakivo-temp
chmod 700 /var/lib/nakivo-temp
df -hT /var/lib/nakivo-temp
```
Kemudian ubah lokasinya pada NAKIVO:
- Settings → Inventory → pve-nakivo → Edit
  → Options → Temporary file location
  → /var/lib/nakivo-temp
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.

Untuk VM Debian atau Ubuntu, jalankan:
```
apt update
apt install -y qemu-guest-agent
systemctl enable --now qemu-guest-agent
```
Setelah itu, aktifkan pada Proxmox:
```
VM → Options → QEMU Guest Agent → Enabled
```
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.

Referensi
August 13, 2026
Cara Mengatasi NAKIVO Replication Gagal karena Temporary Overlay di Proxmox
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.

Membuat Lokasi Temporary Baru

Buat direktori khusus pada filesystem root:
```
mkdir -p /var/lib/nakivo-temp
chown root:root /var/lib/nakivo-temp
chmod 700 /var/lib/nakivo-temp
```
Periksa filesystem yang digunakan:
```
df -hT /var/lib/nakivo-temp
```
Hasilnya harus mengarah ke filesystem root, bukan tmpfs:
```
/dev/mapper/pve-root  ext4  112G  11G  97G  10%  /
```
Uji akses tulis:
```
touch /var/lib/nakivo-temp/test-write
rm /var/lib/nakivo-temp/test-write
```
Mengubah Temporary File Location di NAKIVO

Buka konfigurasi inventory Proxmox pada NAKIVO:
```
Settings
→ Inventory
→ pve-nakivo.local
→ Edit
→ Options
→ Temporary file location
```
Ubah lokasi dari:
```
/tmp
```
menjadi:
```
/var/lib/nakivo-temp
```
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.

Referensi
August 12, 2026

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

Job	Contoh Jadwal
Backup	21.00 WIB
Replication	23.00 WIB

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`

Memahami Kelebihan Proxmox ARM64 untuk Homelab

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:

ARM64 Node 1
     │
ARM64 Node 2
     │
ARM64 Node 3
     │
     └── Ceph Storage

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

August 11, 2026

Hasil Deploy VM Ubuntu di Proxmox dengan Terraform

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.

Hostname	Fungsi	IP Address
`terraform-controller`	Menjalankan Terraform	`192.168.14.80`
`ubuntu-tf-01`	VM hasil Terraform	`192.168.14.81`
`ubuntu-tf-02`	VM hasil Terraform	`192.168.14.82`
`ubuntu-tf-03`	VM hasil Terraform	`192.168.14.83`

Alurnya kurang lebih seperti berikut:

Terraform Controller
192.168.14.80
        │
        │ Proxmox API
        ▼
     Proxmox VE
        │
        ├── ubuntu-tf-01 → 192.168.14.81
        ├── ubuntu-tf-02 → 192.168.14.82
        └── ubuntu-tf-03 → 192.168.14.83

Cara Kerjanya

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.

181  ubuntu-tf-01  → 192.168.14.81
182  ubuntu-tf-02  → 192.168.14.82
183  ubuntu-tf-03  → 192.168.14.83

Masing-masing VM sudah memiliki CPU, RAM, disk, IP statis, Cloud-init, dan SSH key sesuai konfigurasi Terraform.

Ketiga VM juga langsung terlihat pada Proxmox dan berada dalam kondisi Running.

Konfigurasi cloud-init

Untuk memastikan VM benar-benar dapat digunakan, saya mencoba mengakses salah satunya dari Terraform Controller:

ssh ubuntu@192.168.14.81

Artinya VM tidak hanya berhasil dibuat di Proxmox, tetapi juga sudah mendapatkan konfigurasi awal dan dapat diakses melalui SSH.

Terraform State

VM yang dibuat tidak hanya dibuat sekali oleh Terraform, tetapi selanjutnya juga dikelola oleh Terraform.

Resource tersebut dapat dilihat menggunakan:

terraform state list

Contohnya:

proxmox_download_file.ubuntu_cloud_image
proxmox_virtual_environment_vm.ubuntu_vm["ubuntu-tf-01"]
proxmox_virtual_environment_vm.ubuntu_vm["ubuntu-tf-02"]
proxmox_virtual_environment_vm.ubuntu_vm["ubuntu-tf-03"]

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.

Referensi

August 10, 2026

Mengintegrasikan Proxmox dengan Terraform untuk Deploy Virtual Machine

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.

Hostname	Fungsi	IP Address
`terraform-controller`	Terraform Controller	`192.168.14.80`
`ubuntu-tf-01`	VM Target	`192.168.14.81`
`ubuntu-tf-02`	VM Target	`192.168.14.82`
`ubuntu-tf-03`	VM Target	`192.168.14.83`

Konfigurasi Proxmox:

Parameter	Nilai
Node	`pverafi1`
API	`https://192.168.14.31:8006/`
Gateway	`192.168.14.31`
Bridge	`vmbr0`
Image Storage	`local`
VM Storage	`local-lvm`

Alur yang akan dibuat:

Terraform Controller
192.168.14.80
        │
        │ Proxmox API
        ▼
     Proxmox VE
        │
        ├── ubuntu-tf-01 → 192.168.14.81
        ├── ubuntu-tf-02 → 192.168.14.82
        └── ubuntu-tf-03 → 192.168.14.83

1. Menyiapkan Terraform Controller

Saya membuat satu VM Ubuntu Server 24.04 secara manual di Proxmox dengan spesifikasi:

Resource	Konfigurasi
CPU	2 Core
RAM	2 GB
Disk	20 GB
Network	`vmbr0`
IP	`192.168.14.80/24`

VM ini hanya digunakan sebagai controller untuk menjalankan Terraform.

Setelah Ubuntu selesai diinstal, pastikan controller dapat berkomunikasi dengan Proxmox:

ping -c 3 192.168.14.31

2. Install Terraform

Install dependency:

sudo apt update
sudo apt install -y gnupg software-properties-common wget curl

Tambahkan GPG key HashiCorp:

wget -O- https://apt.releases.hashicorp.com/gpg |
gpg --dearmor |
sudo tee /usr/share/keyrings/hashicorp-archive-keyring.gpg > /dev/null

Tambahkan repository:

echo "deb [arch=$(dpkg --print-architecture) signed-by=/usr/share/keyrings/hashicorp-archive-keyring.gpg] https://apt.releases.hashicorp.com $(grep -oP '(?<=UBUNTU_CODENAME=).*' /etc/os-release || lsb_release -cs) main" |
sudo tee /etc/apt/sources.list.d/hashicorp.list

Kemudian install Terraform:

sudo apt update
sudo apt install -y terraform

Verifikasi instalasi:

root@terraform:~/terraform-proxmox# terraform version
Terraform v1.15.8
on linux_amd64

3. Mengaktifkan Import Storage Proxmox

Terraform nantinya akan mengunduh Ubuntu Cloud Image dan memasukkannya ke storage Proxmox.

Buka:

Datacenter
└── Storage
    └── local
        └── Edit

Pada bagian Content, aktifkan:

Import

Ini dibutuhkan agar Terraform dapat menggunakan Ubuntu Cloud Image sebagai sumber disk VM.

4. Membuat User Terraform

Sebaiknya Terraform menggunakan user khusus, bukan akun administrator utama Proxmox.

Buka:

Datacenter
└── Permissions
    └── Users
        └── Add

Buat:

terraform@pve

Untuk percobaan homelab ini saya memberikan role:

Administrator

pada path:

Untuk lingkungan production, permission sebaiknya dibatasi sesuai kebutuhan.

Membuat API Token

Buka:

Datacenter
└── Permissions
    └── API Tokens
        └── Add

Gunakan:

Parameter	Nilai
User	`terraform@pve`
Token ID	`provider`
Privilege Separation	Nonaktif

Setelah dibuat, simpan:

Token secret hanya ditampilkan satu kali.

5. Test Proxmox API

Dari Terraform Controller:

curl -k https://192.168.14.31:8006/api2/json/version

Kemudian masukkan API token sebagai environment variable:

read -rsp "API token: " PROXMOX_VE_API_TOKEN
export PROXMOX_VE_API_TOKEN
echo ${#PROXMOX_VE_API_TOKEN}  -> output harus > 0

Formatnya:

terraform@pve!provider=TOKEN_SECRET

Test autentikasi:

curl -k -H \ "Authorization:PVEAPIToken=${PROXMOX_VE_API_TOKEN}" \
https://192.168.14.31:8006/api2/json/version

Jika berhasil, Proxmox akan mengembalikan informasi versi dalam format JSON.

6. Membuat SSH Key

SSH key nantinya akan dimasukkan ke setiap VM melalui Cloud-init.

ssh-keygen -t ed25519 -C "terraform-controller"

Gunakan lokasi default:

~/.ssh/id_ed25519

7. Membuat Project Terraform

Buat directory:

mkdir -p ~/terraform-proxmox
cd ~/terraform-proxmox

Struktur project:

terraform-proxmox/
├── versions.tf
├── variables.tf
├── main.tf
├── terraform.tfvars
└── outputs.tf

8. Konfigurasi Provider

Buat versions.tf:

terraform {
  required_version = ">= 1.5.0"

  required_providers {
    proxmox = {
      source  = "bpg/proxmox"
      version = "~> 0.111.0"
    }
  }
}

provider "proxmox" {
  endpoint = var.proxmox_endpoint
  insecure = true
}

Saya menggunakan provider bpg/proxmox.

insecure = true digunakan karena Proxmox homelab masih menggunakan sertifikat self-signed.

9. Membuat Variable

Buat variables.tf:

variable "proxmox_endpoint" {
  type = string
}

variable "proxmox_node" {
  type = string
}

variable "image_datastore" {
  type    = string
  default = "local"
}

variable "vm_datastore" {
  type    = string
  default = "local-lvm"
}

variable "bridge" {
  type    = string
  default = "vmbr0"
}

variable "gateway" {
  type = string
}

variable "dns_servers" {
  type    = list(string)
  default = ["8.8.8.8", "1.1.1.1"]
}

variable "ssh_public_key_file" {
  type    = string
  default = "~/.ssh/id_ed25519.pub"
}

10. Mendefinisikan 3 VM Ubuntu

Konfigurasi utama berada pada main.tf.

Pertama, tentukan VM yang ingin dibuat:

locals {
  ubuntu_vms = {
    "ubuntu-tf-01" = {
      vm_id = 181
      ip    = "192.168.14.81/24"
    }

    "ubuntu-tf-02" = {
      vm_id = 182
      ip    = "192.168.14.82/24"
    }

    "ubuntu-tf-03" = {
      vm_id = 183
      ip    = "192.168.14.83/24"
    }
  }
}

Kemudian definisikan Ubuntu Cloud Image:

resource "proxmox_download_file" "ubuntu_cloud_image" {
  content_type = "import"
  datastore_id = var.image_datastore
  node_name    = var.proxmox_node

  url       = "https://cloud-images.ubuntu.com/noble/current/noble-server-cloudimg-amd64.img"
  file_name = "noble-server-cloudimg-amd64.qcow2"

  overwrite = false
}

Selanjutnya resource VM:

resource "proxmox_virtual_environment_vm" "ubuntu_vm" {
  for_each = local.ubuntu_vms

  name        = each.key
  description = "Ubuntu 24.04 deployed by Terraform"
  tags        = ["terraform", "ubuntu"]

  node_name = var.proxmox_node
  vm_id     = each.value.vm_id

  started = true
  on_boot = true

  boot_order    = ["scsi0"]
  scsi_hardware = "virtio-scsi-single"

  cpu {
    cores = 2
    type  = "x86-64-v2-AES"
  }

  memory {
    dedicated = 2048
  }

  disk {
    datastore_id = var.vm_datastore
    import_from  = proxmox_download_file.ubuntu_cloud_image.id
    interface    = "scsi0"
    size         = 20
    discard      = "on"
    iothread     = true
  }

  initialization {
    datastore_id = var.vm_datastore

    dns {
      servers = var.dns_servers
    }

    ip_config {
      ipv4 {
        address = each.value.ip
        gateway = var.gateway
      }
    }

    user_account {
      username = "ubuntu"

      keys = [
        trimspace(
          file(
            pathexpand(var.ssh_public_key_file)
          )
        )
      ]
    }
  }

  network_device {
    bridge = var.bridge
    model  = "virtio"
  }

  operating_system {
    type = "l26"
  }

  serial_device {}
}

Dengan looping for_each, satu resource dapat digunakan untuk mendefinisikan tiga VM sekaligus.

Target konfigurasinya:

VM	VM ID	IP	CPU	RAM	Disk
`ubuntu-tf-01`	181	`192.168.14.81`	2 Core	2 GB	20 GB
`ubuntu-tf-02`	182	`192.168.14.82`	2 Core	2 GB	20 GB
`ubuntu-tf-03`	183	`192.168.14.83`	2 Core	2 GB	20 GB

11. Konfigurasi Environment Homelab

Buat terraform.tfvars:

proxmox_endpoint = "https://192.168.14.31:8006/"
proxmox_node     = "pverafi1"

image_datastore = "local"
vm_datastore    = "local-lvm"

bridge  = "vmbr0"
gateway = "192.168.14.31"

dns_servers = [
  "8.8.8.8",
  "1.1.1.1"
]

ssh_public_key_file = "~/.ssh/id_ed25519.pub"

Nama node dapat diperiksa pada Proxmox:

hostname

Sedangkan storage:

pvesm status

12. Membuat Output

Buat outputs.tf:

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.

Referensi

HashiCorp Terraform Documentation
bpg/proxmox Terraform Provider
Proxmox VE Documentation
Ubuntu Cloud Images

August 7, 2026

Memilih Storage Proxmox Sesuai Kebutuhan: Homelab hingga Production

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.

Referensi

Homelab Storage Guide: ZFS, Ceph, PBS, Unraid, NFS, iSCSI — Mr.PlanB

Ceph Is a Beast, ZFS Just Works: Inside the Storage Wars of the Proxmox Community — Mr.PlanB

August 6, 2026

Mengenal Otomatisasi Homelab Proxmox dengan Terraform dan Ansible

Membuat virtual machine di Proxmox melalui web interface cukup mudah. Namun, jika VM yang dibuat semakin banyak, proses mengatur CPU, RAM, disk, jaringan, dan sistem operasi secara manual akan terasa berulang.

Artikel ini membahas cara mengotomatisasi homelab Proxmox menggunakan Terraform, Cloud-init, dan Ansible.

Gambaran Homelab

Dalam skenario ini, Terraform digunakan untuk membuat tiga virtual machine Ubuntu di Proxmox.

Setelah VM tersedia, Cloud-init memasukkan SSH key. Selanjutnya, Ansible terhubung ke masing-masing VM untuk menginstal Docker dan menjalankan container.

Alur Otomatisasi

File konfigurasi
       │
       ▼
Terraform
Membuat 3 VM Ubuntu
       │
       ▼
Cloud-init
Memasukkan SSH key
       │
       ▼
Ansible
Menginstal Docker
       │
       ▼
Container berjalan

Fungsi Setiap Komponen

Komponen	Fungsi
Proxmox	Menjalankan virtual machine
Terraform	Membuat dan mengelola VM
Cloud-init	Menyiapkan konfigurasi awal dan SSH key
Ansible	Mengatur server setelah VM tersedia
Docker	Menjalankan aplikasi dalam container

Peran Terraform

Terraform digunakan untuk menyediakan infrastruktur di Proxmox.

Konfigurasi VM seperti nama, CPU, RAM, disk, dan jaringan dituliskan dalam file Terraform. Dengan demikian, VM tidak perlu dibuat satu per satu melalui web interface.

Terraform juga menyimpan state untuk mencatat infrastruktur yang sudah dibuat dan perubahan yang perlu diterapkan.

Peran Cloud-init

Cloud-init menjalankan konfigurasi awal ketika VM pertama kali dibuat.

Dalam artikel ini, Cloud-init digunakan untuk memasukkan SSH key ke dalam VM Ubuntu. SSH key tersebut memungkinkan Ansible masuk ke server tanpa menggunakan password secara manual.

Peran Ansible

Setelah VM aktif dan dapat diakses melalui SSH, Ansible menjalankan konfigurasi di dalam server.

Tugas Ansible dalam skenario ini meliputi:

Menghubungkan ke VM melalui SSH.
Menginstal Docker.
Menyiapkan kebutuhan server.
Menjalankan container.

Terraform dan Ansible

Terraform dan Ansible memiliki tugas yang berbeda.

Terraform	Ansible
Membuat infrastruktur	Mengonfigurasi server
Membuat virtual machine	Menginstal aplikasi
Mengelola resource Proxmox	Menjalankan Docker dan container
Menggunakan state	Menggunakan inventory dan playbook

Secara sederhana:

Terraform membuat server, sedangkan Ansible mengatur isi server.

Keuntungan Pendekatan Ini

Dengan menyimpan konfigurasi sebagai kode, homelab menjadi:

Lebih konsisten.
Mudah dibuat ulang.
Tidak bergantung pada langkah manual.
Dapat disimpan dalam version control.
Lebih mudah dikelola ketika jumlah VM bertambah.

Rencana Percobaan di Homelab

Untuk mempraktikkan skenario ini, saya akan menggunakan satu VM sebagai controller dan tiga VM Ubuntu sebagai target. Seluruh server berada pada network 192.168.14.0/24.

Rancangan IP Address

Hostname	Fungsi	IP Address
`automation-controller`	Menjalankan Terraform dan Ansible	`192.168.14.80`
`ubuntu-target01`	VM target pertama	`192.168.14.81`
`ubuntu-target02`	VM target kedua	`192.168.14.82`
`ubuntu-target03`	VM target ketiga	`192.168.14.83`

Konfigurasi jaringan yang digunakan:

Konfigurasi	Nilai
Network	`192.168.14.0/24`
Gateway	`192.168.14.31`
Proxmox bridge	`vmbr0`
Metode IP	Static melalui Cloud-init

Topologi Homelab

                    Network 192.168.14.0/24
                              │
                    Proxmox VE / vmbr0
                              │
          ┌───────────────────┴───────────────────┐
          │                                       │
automation-controller                     VM Target Ubuntu
   192.168.14.80                    ┌────────────────────────┐
   Terraform                        │ target01 192.168.14.81 │
   Ansible                          │ target02 192.168.14.82 │
                                   │ target03 192.168.14.83 │
                                   └────────────────────────┘

Alur Percobaan

Menyiapkan VM automation-controller.
Menginstal Terraform dan Ansible pada controller.
Menyiapkan template Ubuntu Cloud-init di Proxmox.
Menghubungkan Terraform dengan Proxmox.
Menjalankan Terraform untuk membuat tiga VM target.
Cloud-init mengatur hostname, IP address, user, dan SSH key.
Ansible mengakses seluruh VM target melalui SSH.
Ansible menginstal Docker dan menjalankan container.
Memastikan seluruh VM dan container berjalan dengan baik.

Pembagian Tugas

Tahap	Tools
Membuat VM di Proxmox	Terraform
Mengatur IP dan SSH key	Cloud-init
Menginstal Docker	Ansible
Menjalankan aplikasi	Docker container

Hasil yang Diharapkan

Setelah percobaan selesai, tiga VM Ubuntu dapat dibuat secara otomatis tanpa konfigurasi manual melalui web interface Proxmox.

Seluruh VM memiliki IP statis, dapat diakses melalui SSH dari controller, dan sudah menjalankan Docker serta container yang ditentukan melalui Ansible.

Kesimpulan

Artikel ini menunjukkan cara menggabungkan Proxmox, Terraform, Cloud-init, dan Ansible untuk membangun homelab otomatis.

Terraform membuat tiga VM Ubuntu, Cloud-init menyiapkan SSH key, kemudian Ansible menginstal Docker dan menjalankan container.

Dengan pembagian tersebut, proses pembangunan homelab menjadi lebih terstruktur, dapat diulang, dan lebih mudah dikelola.

Referensi

Proxmox Homelab Automation with Ansible & Terraform
https://proxmox.mrplanb.com/proxmox-ansible-terraform-homelab

August 5, 2026

Memahami Zimlet pada Zimbra

Zimbra bukan hanya sekadar mail server yang menyediakan layanan email, kalender, kontak, dan task. Salah satu fitur yang membuat Zimbra fleksibel adalah Zimlet, sebuah mekanisme yang memungkinkan system admin maupun developer mengintegrasikan Zimbra dengan aplikasi, layanan, atau sistem lain tanpa harus mengubah kode inti Zimbra. Zimlet telah menjadi salah satu fitur unggulan sejak awal pengembangan Zimbra dan terus berkembang hingga versi modern.

Pada artikel ini kita akan membahas apa itu Zimlet, bagaimana cara kerjanya, jenis-jenis Zimlet, contoh implementasinya, hingga cara admin mengelolanya di server Zimbra.

Apa Itu Zimlet?

Zimlet adalah ekstensi (plugin) yang dirancang untuk menambahkan kemampuan baru pada Zimbra Collaboration. Dengan Zimlet, informasi di dalam email dapat menjadi interaktif (actionable content) sehingga pengguna dapat berinteraksi langsung dengan aplikasi atau layanan lain tanpa meninggalkan antarmuka Zimbra.

Sederhananya, Zimlet dapat:

Menambahkan menu baru pada antarmuka Zimbra.
Menghubungkan email dengan aplikasi pihak ketiga.
Menampilkan informasi tambahan ketika pengguna mengarahkan kursor ke suatu objek.
Menambahkan fitur drag-and-drop.
Menambahkan tab atau panel baru pada Zimbra Web Client.

Mengapa Zimlet Dibuat?

Pada umumnya, ketika menerima email yang berisi alamat, nomor resi, atau nomor penerbangan, pengguna harus membuka browser lalu mencari informasi tersebut secara manual.

Dengan Zimlet, proses tersebut menjadi jauh lebih sederhana.

Contohnya:

Alamat pada email langsung dapat dibuka di Google Maps.
Nomor penerbangan dapat menampilkan status penerbangan secara real-time.
Nomor tiket helpdesk langsung membuka halaman tiket.
Nomor telepon dapat langsung dihubungkan ke aplikasi VoIP.
Link meeting dapat langsung membuka Zoom atau Microsoft Teams.

Semua proses tersebut berlangsung tanpa harus keluar dari Zimbra.

Contoh Zimlet Bawaan Zimbra

Beberapa Zimlet sudah tersedia secara default pada instalasi Zimbra.

Contohnya:

Zimlet	Fungsi
URL	Preview website
Email	Menampilkan informasi kontak
Calendar	Membuka jadwal pada tanggal tertentu
Phone	Integrasi VoIP
Maps	Membuka lokasi pada peta
Skype / Zoom (tergantung versi)	Membuka aplikasi meeting

Admin dapat mengaktifkan atau menonaktifkan Zimlet sesuai kebutuhan.

Jenis-Jenis Zimlet

Secara umum terdapat beberapa jenis Zimlet.

1. Content Zimlet

Jenis ini bekerja dengan mendeteksi pola tertentu pada isi email.

Misalnya:

alamat email
URL
tanggal
nomor telepon
alamat fisik

Kemudian objek tersebut dibuat menjadi interaktif.

2. Panel Zimlet

Panel Zimlet muncul pada panel sebelah kiri Zimbra.

Biasanya digunakan sebagai launcher aplikasi.

Contohnya:

CRM
Helpdesk
ERP
Dashboard internal

Pengguna dapat melakukan drag-and-drop email ke Panel Zimlet untuk menjalankan aksi tertentu.

3. Tab Zimlet

Jenis ini membuat tab baru pada menu utama Zimbra.

Contohnya:

Mail
Calendar
Contacts
Tasks
CRM
Helpdesk
Inventory

Dengan begitu aplikasi perusahaan dapat diakses langsung dari dalam Zimbra.

4. Integrated Zimlet

Jenis ini merupakan Zimlet yang terintegrasi lebih dalam dengan antarmuka Zimbra.

Contohnya:

menambahkan tombol baru
menambahkan menu klik kanan
membuat dialog baru
mengubah perilaku UI tertentu

Jenis ini biasanya digunakan pada implementasi enterprise.

Struktur Dasar Zimlet

Sebuah paket Zimlet biasanya didistribusikan dalam bentuk file ZIP yang berisi beberapa komponen.

Contohnya:

com_example_demo.zip

├── com_example_demo.xml
├── com_example_demo.js
├── com_example_demo.properties
├── config_template.xml
├── images/
├── css/
└── jsp/

Penjelasan singkat:

File	Fungsi
XML	Mendefinisikan Zimlet
JS	Logika JavaScript
JSP	Komunikasi server (opsional)
Properties	Multi bahasa
CSS	Tampilan
Images	Ikon

File yang paling penting adalah file XML, karena di sinilah perilaku dasar Zimlet didefinisikan.

Mengelola Zimlet di Zimbra

System admin dapat mengelola Zimlet menggunakan utilitas zmzimletctl.

Melihat daftar Zimlet

su - zimbra

zmzimletctl listZimlets

Deploy Zimlet

zmzimletctl deploy nama-zimlet.zip

Menonaktifkan Zimlet

zmzimletctl disable nama_zimlet

Mengaktifkan kembali

zmzimletctl enable nama_zimlet

Menghapus Zimlet

zmzimletctl undeploy nama_zimlet

Perintah-perintah tersebut memungkinkan admin mengelola siklus hidup Zimlet langsung dari command line.

Kesimpulan

Zimlet merupakan salah satu fitur yang menjadikan Zimbra lebih dari sekadar mail server. Dengan kemampuannya mengintegrasikan email dengan aplikasi dan layanan lain, Zimlet mampu meningkatkan produktivitas pengguna sekaligus menyederhanakan alur kerja di lingkungan perusahaan.

Bagi system admin, Zimlet dapat dikelola dengan mudah melalui zmzimletctl, sedangkan bagi developer, Zimlet menyediakan kerangka kerja yang fleksibel untuk membangun integrasi dengan berbagai sistem internal maupun layanan pihak ketiga. Memahami konsep dan cara kerja Zimlet menjadi langkah awal yang penting sebelum mulai mengembangkan atau menerapkan integrasi pada lingkungan Zimbra.

Referensi

Zimbra Wiki – Zimlets
https://wiki.zimbra.com/wiki/Zimlets
GitHub – Zimbra Zimlet Guide
Zimbra zm-zimlet-guide Repository
Zimbra Developers Guide (Modern UI Zimlet Development)
https://wiki.zimbra.com/wiki/DevelopersGuide#Zimlet_Development_Guide

August 4, 2026

Cara Mengatasi zmamavisdctl Gagal Start Setelah Upgrade Zimbra NE 10.1.20

Saya memiliki server Zimbra Collaboration Network Edition 10.1.16 yang sudah cukup lama tidak diperbarui. Setelah melakukan upgrade (patching) ke Zimbra 10.1.20, seluruh proses upgrade berjalan dengan baik, namun terdapat satu masalah, yaitu service Amavis (zmamavisdctl) gagal dijalankan.

Akibatnya:

Service amavis berstatus Stopped.
Service antivirus dan mta juga ikut berhenti.
Email tidak dapat diproses karena Postfix gagal terhubung ke Amavis.

Gejala

Cek status service:

zmcontrol status

Hasil:

zimbra@mail:~$ zmcontrol status
Host mail.zimbra.lab
        amavis                  Stopped
                amavisd is not running.
        antispam                Stopped
                zmamavisdctl is not running
        antivirus               Stopped
                zmamavisdctl is not running
        convertd                Running
        ldap                    Running
        license-daemon          Running
        logger                  Running
        mailbox                 Running
        memcached               Running
        mta                     Stopped
                zmamavisdctl is not running
        onlyoffice              Running
        opendkim                Running
        proxy                   Running
        service webapp          Running
        snmp                    Running
        spell                   Running
        stats                   Running
        zimbra webapp           Running
        zimbraAdmin webapp      Running
        zimlet webapp           Running
        zmconfigd               Running

Log Postfix menunjukkan:

connect to 127.0.0.1:10026: Connection refused

Artinya Amavis tidak berhasil membuka port filtering SMTP.

Proses Troubleshooting

1. Pastikan penyebab

Jalankan:

su - zimbra

/opt/zimbra/common/sbin/amavisd \
-X no_conf_file_writable_check \
-c /opt/zimbra/conf/amavisd.conf \
test-config

Jika tidak ada output, berarti konfigurasi Amavis valid.

2. Jalankan Amavis secara foreground

/opt/zimbra/common/sbin/amavisd \
-X no_conf_file_writable_check \
-c /opt/zimbra/conf/amavisd.conf \
foreground

Didapatkan error:

zimbra@mail:~$ /opt/zimbra/common/sbin/amavisd \
-X no_conf_file_writable_check \
-c /opt/zimbra/conf/amavisd.conf \
foreground

Suicide () TROUBLE in pre_loop_hook: config: no rules were found!  Do you need to run 'sa-update'?
Compilation failed in require at /opt/zimbra/common/sbin/amavisd line 101.
BEGIN failed--compilation aborted at /opt/zimbra/common/sbin/amavisd line 101.

3. Periksa SpamAssassin

Lakukan pengecekan:

/opt/zimbra/common/bin/spamassassin --lint -D

Hasil akhirnya menunjukkan:

zimbra@mail:~$ /opt/zimbra/common/bin/spamassassin --lint -D
.
.
.
config: no rules were found!  Do you need to run 'sa-update'?

Padahal direktori rules masih lengkap.

4. Jalankan sa-update

/opt/zimbra/common/bin/sa-update -D

Didapatkan error:

zimbra@mail:~$ /opt/zimbra/common/bin/sa-update -D
.
.
Aug  3 12:05:57.745 [47987] dbg: gpg: [GNUPG:] NO_PUBKEY 6C55397824F434CE
Aug  3 12:05:57.745 [47987] dbg: gpg: gpg: Can't check signature: No public key
.
.
NO_PUBKEY
error: GPG validation failed!

Dari sini diketahui bahwa GPG key SpamAssassin hilang, sehingga proses update rules gagal diverifikasi.

Solusi

1. Buat direktori key

mkdir -p /opt/zimbra/data/spamassassin/localrules/sa-update-keys
chown -R zimbra:zimbra /opt/zimbra/data/spamassassin/localrules

2. Download GPG Key resmi

cd /tmp
wget https://spamassassin.apache.org/updates/GPG.KEY

3. Import GPG Key

Jalankan sebagai user zimbra.

su - zimbra
/opt/zimbra/common/bin/sa-update --import /tmp/GPG.KEY

4. Update SpamAssassin Rules

/opt/zimbra/common/bin/sa-update

Pastikan proses selesai tanpa error GPG.

5. Restart Service

zmamavisdctl restart

atau

zmcontrol restart

Verifikasi

Pastikan service kembali berjalan:

zmcontrol status

Hasil yang diharapkan:

zimbra@mail:~$ zmcontrol status
Host mail.zimbra.lab
        amavis                  Running
        antispam                Running
        antivirus               Running
        convertd                Running
        ldap                    Running
        license-daemon          Running
        logger                  Running
        mailbox                 Running
        memcached               Running
        mta                     Running
        onlyoffice              Running
        opendkim                Running
        proxy                   Running
        service webapp          Running
        snmp                    Running
        spell                   Running
        stats                   Running
        zimbra webapp           Running
        zimbraAdmin webapp      Running
        zimlet webapp           Running
        zmconfigd               Running

Lalu pastikan dapat mengirim email secara normal kembali.

Kesimpulan

Kasus ini terjadi setelah melakukan upgrade dari Zimbra 10.1.16 ke 10.1.20 pada server yang sudah lama tidak diperbarui. Penyebab utamanya bukan pada konfigurasi Amavis, melainkan GPG key SpamAssassin yang hilang, sehingga proses sa-update gagal memverifikasi update rules. Akibatnya, SpamAssassin tidak dapat memuat rules dan Amavis gagal dijalankan.

Dengan mengembalikan GPG key, menjalankan kembali sa-update, dan me-restart service Zimbra, service amavis, antivirus, dan mta dapat kembali berjalan normal.

Referensi

August 3, 2026

Author: Rafi Harlianto

Homelab yang Digunakan

Hasil Pengujian

Penyebabnya

Pengujian Lanjutan

Kesimpulan

Referensi

Homelab yang Digunakan

1. Ubah Lokasi Temporary Overlay

2. Pastikan VM Sumber Menyala

3. Pasang dan Aktifkan QEMU Guest Agent

4. Pisahkan Jadwal Backup dan Replication

Verifikasi Hasil Replication

Penutup

Referensi

Kondisi Lab

Pesan Error

Memahami Alur Replication NAKIVO

Penyebab

Membuat Lokasi Temporary Baru

Mengubah Temporary File Location di NAKIVO

Menjalankan Ulang Replication

Catatan Penting

Kesimpulan

Referensi

ARM64 Itu Apa?

1. Proxmox Bisa Berjalan pada Hardware yang Lebih Hemat Daya

2. Bukan Proxmox Versi “Lite”

3. ZFS dan Ceph Tetap Tersedia

4. Homelab Bisa Menjadi Lebih Kecil

Apakah Bisa Menggunakan Raspberry Pi?

ARM64 Belum Menggantikan x86

Jadi Apa Kelebihan Proxmox ARM64?

Kesimpulan

Referensi

Topologi homelab

Cara Kerjanya

Menjalankan Plan yang Sudah Disimpan

Hasil Deployment

Terraform State

Kesimpulan

Referensi

Rancangan Homelab

1. Menyiapkan Terraform Controller

2. Install Terraform

3. Mengaktifkan Import Storage Proxmox

4. Membuat User Terraform

Membuat API Token

5. Test Proxmox API

6. Membuat SSH Key

7. Membuat Project Terraform

8. Konfigurasi Provider

9. Membuat Variable

10. Mendefinisikan 3 VM Ubuntu

11. Konfigurasi Environment Homelab

12. Membuat Output

13. Inisialisasi dan Validasi Terraform

14. Melihat Terraform Plan

Referensi

Mulai dari kebutuhan

1. Storage lokal untuk single node

2. Cluster kecil: storage lokal atau shared NAS

ZFS Replication

NFS atau iSCSI

3. Scale dan High Availability dengan Ceph

4. Backup tetap menggunakan PBS

Rangkuman pilihan untuk Proxmox

Kesimpulan

Referensi

Gambaran Homelab

Alur Otomatisasi

Fungsi Setiap Komponen

Peran Terraform

Peran Cloud-init

Peran Ansible

Terraform dan Ansible

Keuntungan Pendekatan Ini

Rencana Percobaan di Homelab

Rancangan IP Address

Topologi Homelab