Category: Proxmox

Catatan Belajar Proxmox: Memahami Advisory PinTheft (PSA-2026-00022-1)
Halo teman-teman, di post kali ini saya mau share catatan belajar yang baru saya dapat terkait Proxmox. Tepatnya soal security advisory yang dirilis tim Proxmox tanggal 19 Mei 2026 kemarin.

Belakangan ini saya memang sedang fokus mendalami Proxmox VE dari berbagai sisi, mulai dari cluster setup, Ceph, ZFS replication, sampai topik-topik advanced lainnya. Kebetulan Pak Ahmad Imanudin, lead engineer di PT. Excellent Infotama Kreasindo, kasih link forum advisory Proxmox dan bilang ada update security yang patut dipelajari. Setelah saya baca, isinya cukup menarik dan saya pikir worth banget di-dokumentasikan di blog ini sebagai catatan pembelajaran.

Post ini hanya merupakan penjelasan saja sebagai catatan belajar saya pribadi. Jadi, bukan panduan mitigasi atau eskalasi nya. Saya bukan ahli security, jadi kalau ada teman-teman yang lebih ahli dan ada bagian yang salah, mohon koreksi di kolom komentar.

Apa Itu Security Advisory di Proxmox

Hal pertama yang baru saya pahami adalah cara Proxmox merilis security advisory. Mereka secara berkala publish di thread forum resmi mereka. Format penomorannya seperti ini:
```
PSA-{tahun}-{nomor-urut}-{revisi}
```
Misalnya PSA-2026-00022-1 artinya advisory nomor 22 di tahun 2026, revisi 1.

Konten advisory biasanya terdiri dari beberapa bagian. Subject yang berisi codename plus dampak singkat. Affected packages yang menjelaskan package mana yang kena. Details yang berisi penjelasan singkat root cause. Mitigation yang menjelaskan langkah workaround sebelum fix tersedia. Dan Fixed in yang nantinya akan diisi versi yang sudah patched.

Advisory kali ini membahas codename “PinTheft”, sebuah Local Privilege Escalation di kernel Proxmox.

Mengenal PinTheft

PinTheft adalah teknik gabungan dari dua hal itu. Langkah-langkahnya berdasarkan write-up yang saya baca:
1. Attacker pakai io_uring untuk pinning halaman memori dengan banyak reference.
2. Pakai bug double-free di RDS untuk “mencuri” reference satu per satu.
3. Setelah cukup banyak reference dicuri, halaman dianggap free oleh kernel.
4. Halaman itu dialokasikan ulang sebagai page cache untuk binary SUID-root, contohnya /usr/bin/su, /usr/bin/passwd, /usr/bin/pkexec, atau /usr/bin/mount.
5. Pakai pointer io_uring yang sudah stale, attacker overwrite isi binary itu di memori dengan payload ELF kecil.
6. Begitu binary SUID dijalankan, attacker dapat root shell.
Jadi kombinasi dua bug yang masing-masing terlihat “kecil” bisa jadi exploit chain yang serius kalau digabungkan. Ini pelajaran penting tentang attack chaining yang sering dibahas di security research.

Konteks Local Privilege Escalation (LPE)

Bagi yang belum familiar dengan istilah LPE, ada dua kata yang perlu dipahami. Local artinya penyerang sudah punya akses ke sistem, entah user SSH biasa, kompromi akun service, container escape, atau code di VM yang lolos isolation. Privilege Escalation artinya naik dari user biasa jadi root.

Jadi LPE tidak bisa diserang dari internet langsung, butuh foothold dulu. Tapi di lingkungan multi-tenant atau yang banyak service running, foothold itu sering lebih mudah didapat daripada yang kita kira. Itulah kenapa LPE tetap dianggap serius meskipun bukan remote.

Yang terkena dampak

Berdasarkan advisory, semua package proxmox-kernel-*. Belum ada versi kernel yang fixed di tulisan advisory ini, Proxmox bilang akan publish advisory follow-up begitu ada fix tersedia.

Pemahaman Tentang Advisory
- Pertama, target-nya adalah kernel hypervisor, bukan kernel VM. Artinya yang perlu di-mitigasi adalah Proxmox host, bukan VM-VM di dalamnya.
- Kedua, dampak root di Proxmox host itu sangat besar. Begitu attacker dapat root di node Proxmox, secara teori mereka bisa akses semua VM, semua storage, semua data. Worst case scenario untuk infrastruktur IT.
- Ketiga, ada tren yang menurut saya patut dicatat. Ini bukan advisory tunggal. Tanggal 8 Mei 2026 sebelumnya sudah ada advisory PSA-2026-00019-1 codename “Dirty Frag” yang juga LPE via modul kernel yang auto-loaded (esp4, esp6, rxrpc). Pattern-nya sama, yaitu modul kernel jarang dipakai, auto-loaded saat ada request socket family dari user, dan ada bug yang bisa di-exploit untuk LPE. Tren ini kasih saya pelajaran bahwa attack surface kernel yang seringkali tidak kita sadari adalah modul-modul yang bisa di-load otomatis hanya dengan request socket family tertentu dari user biasa.
- Keempat, PoC sudah publik. Tim V12 Security sudah rilis Proof-of-Concept-nya di GitHub setelah patch upstream tersedia. Artinya secara teori exploit ini sudah bisa diakses publik dan harus segera di-mitigasi.
Mitigasi yang Disarankan Proxmox

Bagian ini saya tulis berdasarkan apa yang tertera di advisory. Karena saya masih dalam tahap belajar, saya hanya mencantumkan mitigasi yang disarankan Proxmox. Saran saya selalu sesuaikan dengan environment masing-masing dan baca advisory aslinya langsung.

Sambil tunggu kernel fix rilis, ada tiga langkah utama yang disarankan Proxmox.

Langkah pertama adalah cek apakah modul sudah ter-load:
```
lsmod | grep -e rds -e rds_tcp
```
Kalau output kosong artinya aman, modul belum ter-load. Kalau ada output dan tidak sedang pakai RDS untuk workload tertentu, ini bisa jadi indikasi auto-load atau bahkan upaya exploit, perlu di-investigasi lebih dulu sebelum unload.

Langkah kedua adalah mencegah modul ke-load di masa depan:
```
sh -c "printf 'install rds /bin/false\ninstall rds_tcp /bin/false' > /etc/modprobe.d/pintheft.conf"
```
Trik ini menggunakan install directive di modprobe yang me-redirect proses loading modul ke /bin/false (program yang langsung exit dengan error). Hasilnya, setiap upaya load modul rds atau rds_tcp bakal gagal, baik dari root maupun user biasa.

Langkah ketiga adalah unload modul yang sudah ter-load kalau ada:
```
rmmod rds_tcp rds
```
Lalu untuk verifikasi mitigasi aktif, bisa coba load manual modul dan lihat outputnya:
```
modprobe rds
```
Output bakal berisi error karena modprobe sebenarnya ngeksekusi /bin/false, bukan benar-benar load modul.

Yang menarik, mitigasi ini tidak perlu reboot. Begitu file /etc/modprobe.d/pintheft.conf dibuat dan modul yang sudah load di-unload, mitigasi langsung berlaku.

Pelajaran yang Saya Ambil

Dari proses belajar advisory ini, ada beberapa pelajaran yang saya tarik dan ingin dokumentasikan di sini.
- Pertama, security advisory Proxmox itu tidak digembar-gemborkan di mana-mana. Biasanya cuma di-publish di thread forum mereka. Buat saya yang sebelumnya mungkin tidak rutin mengecek forum, ini reminder bahwa subscribe ke thread advisory mereka itu penting. Linknya saya cantumkan di akhir post.
- Kedua, mekanisme auto-loading modul kernel ternyata adalah attack surface yang halus tapi serius. User biasa secara teori bisa memaksa kernel me-load modul-modul tertentu hanya dengan membuka socket dengan address family tertentu. Kalau modul itu ternyata vulnerable, jadilah LPE seperti PinTheft ini.
- Ketiga, defense-in-depth kelihatan makin relevan. Selain apply mitigasi spesifik, audit modul kernel yang tidak terpakai mungkin perlu jadi bagian dari hardening checklist. Modul-modul jaringan jarang dipakai seperti RDS, DCCP, SCTP, RxRPC, dan ESP, atau filesystem driver yang exotic seperti NTFS3 atau JFS, beberapa di antaranya sering jadi vector LPE.
- Keempat, patch management hygiene jadi makin penting. Begitu kernel fix dari Proxmox tersedia, sebaiknya tidak ditunda terlalu lama. Untuk environment cluster, tinggal migrasi VM ke node lain dulu, baru reboot satu per satu.
Penutup

Selain belajar hal baru tentang kernel security, saya juga jadi sadar bahwa banyak hal “low-profile” tapi berdampak besar yang harus mulai dipantau secara rutin sebagai admin infrastructure. Sebelumnya saya kira advisory begini cuma muncul kalau ada CVE besar yang viral di Twitter atau media tech, ternyata ada banyak yang muncul senyap di forum tapi sebenarnya butuh tindakan cepat.

Mudah-mudahan catatan belajar ini bermanfaat untuk teman-teman yang sedang mendalami Proxmox dan ingin memahami lebih dalam soal sisi security-nya. Kalau ada teman-teman yang lebih ahli dan punya koreksi atau tambahan terkait pemahaman saya ini, bisa komen ya di kolom komentar.

Sumber:
- Thread Advisory Proxmox: https://forum.proxmox.com/threads/proxmox-virtual-environment-security-advisories.149331/page-3
- PoC dan write-up V12 Security: https://github.com/v12-security/pocs/tree/main/pintheft
- oss-security mailing list announcement: https://www.openwall.com/lists/oss-security/2026/05/19/6
May 20, 2026
Mengatasi Mismatch Versi DRBD di LINSTOR
Beberapa waktu terakhir saya sedang mendalami implementasi storage terdistribusi menggunakan LINSTOR di cluster Proxmox VE. Tujuannya sederhana: membuat storage yang bisa direplikasi antar node (HA) sehingga VM tetap aman walaupun salah satu node mati. Semua setup awal terlihat normal—node sudah terdaftar, storage pool sudah dibuat, dan integrasi ke Proxmox juga sudah masuk.

Namun saat mencoba clone VM ke storage LINSTOR, muncul error autoplace yang cukup membingungkan. Setelah ditelusuri, ternyata akar masalahnya bukan di konfigurasi storage pool atau resource group, melainkan di layer yang lebih dalam: versi DRBD yang tidak selaras antara kernel dan userspace. Di sinilah perjalanan troubleshooting dimulai.

Mengenal DRBD dan LINSTOR

Sebelum masuk ke teknis, kita pahami dulu perannya:
- DRBD adalah teknologi replikasi block storage (mirip RAID 1 tapi via network).
- LINSTOR adalah orchestrator yang mengatur DRBD secara otomatis di banyak node.
Secara sederhana:
- DRBD = mesin replikasi
- LINSTOR = otaknya
LINSTOR tidak menyimpan data sendiri, tapi memanfaatkan DRBD untuk membuat disk yang direplikasi antar node.

Masalah yang Terjadi

Saat melakukan pengecekan:
```
linstor node info
```
Hasilnya:

Padahal:
- drbdadm ada
- modprobe drbd berhasil
- service linstor jalan normal
Pas dicek lebih dalam:
```
cat /proc/drbd
```
Output:
```
version: 8.4.11 ()
```
Sementara:
```
dkms status
```
Output:
```
drbd/9.3.2-1, 7.0.0-3-pve, x86_64: installed ()
```
Intinya

Terjadi mismatch versi DRBD:

Komponen Versi
Kernel module DRBD 8 ❌
Userspace DRBD 9 ✔️

Masalahnya:
- LINSTOR hanya support DRBD 9
- DRBD 8 dianggap tidak ada
Kenapa Bisa Terjadi?

Kernel Proxmox secara default masih membawa DRBD 8. Saat menjalankan:
```
modprobe drbd
```
Yang ter-load bukan DRBD 9 dari DKMS, tapi DRBD 8 bawaan kernel

Akibatnya:
- DRBD terlihat “aktif”
- tapi tidak usable oleh LINSTOR
Solusi: Selaraskan Versi DRBD

Berikut langkah yang saya lakukan untuk memperbaiki mismatch ini.

1. Blacklist DRBD lama (bawaan kernel)
```
echo "blacklist drbd" > /etc/modprobe.d/blacklist-drbd.conf
```
2. Update initramfs
```
update-initramfs -u
```
3. Reboot semua node
```
reboot
```
Lakukan di semua node cluster

4. Load ulang DRBD
```
modprobe drbd
```
5. Verifikasi versi DRBD
```
cat /proc/drbd
```
Hasil yang benar:

6. Restart LINSTOR
```
systemctl restart linstor-satellite
systemctl restart linstor-controller
```
7. Cek ulang LINSTOR
```
linstor node info
```
Hasil:

Hasil Akhir

Setelah versi DRBD selaras:
- Clone VM berhasil
- Resource bisa autoplace ke semua node
- Replikasi berjalan normal
Error sebelumnya hilang
```
does not support the following layers: [DRBD]
```
Insight Penting (Pelajaran yang Didapat)

Beberapa hal penting yang saya pelajari dari kasus ini:
- DRBD harus versi yang sama untuk LINSTOR
- modprobe drbd tidak menjamin versi yang digunakan benar
- Selalu cek versi dari drbd di /proc/drbd
- Kernel module bisa override DKMS jika tidak di-blacklist
- LINSTOR sangat bergantung pada layer DRBD yang valid
Kesimpulan

Masalah yang terlihat seperti error konfigurasi LINSTOR ternyata berasal dari layer paling bawah: kernel module DRBD. Ini menunjukkan bahwa dalam implementasi storage terdistribusi, setiap layer harus selaras—mulai dari kernel, userspace, hingga orchestration.

Dengan memastikan DRBD versi 9 aktif di semua node, LINSTOR dapat bekerja optimal dan seluruh fitur seperti replication, HA, dan cloning bisa berjalan dengan lancar.
May 5, 2026
Membuat Linux Bond dan Linux Bridge di Proxmox VE
Salah satu keuntungan menggunakan Proxmox VE sebagai hypervisor adalah fleksibilitas konfigurasi jaringannya. Kita bisa membuat bonding antar NIC fisik untuk mendapatkan redundansi atau agregasi bandwidth, lalu menempatkan bridge virtual di atasnya agar bisa dipakai oleh VM. Di tulisan ini saya akan dokumentasikan prosesnya step by step, mulai dari kondisi awal sampai bridge baru siap digunakan oleh VM.

Kondisi Awal Jaringan

Node Proxmox saya (rafi1) sudah punya beberapa antarmuka jaringan yang aktif. Tiga NIC fisik pertama sudah terpasang masing-masing ke bridge Linux tersendiri:
- ens18 → vmbr0
- ens19 → vmbr1
- ens20 → vmbr2
Kemudian saya menambahkan 2 NIC, kedua NIC ini akan saya gabungkan menggunakan Linux Bond, lalu di atasnya saya buatkan sebuah bridge baru.

Add -> Network Device

Klik Add (biarkan default)

ens 21 dan ens 22 siap di bond

Mengapa Menggunakan Linux Bond?

Linux Bonding memungkinkan kita menggabungkan dua atau lebih NIC fisik menjadi satu antarmuka logis. Ada beberapa mode yang tersedia, dan masing-masing punya karakteristik berbeda. Mode balance-rr (round-robin) bekerja dengan mendistribusikan paket secara bergantian ke semua slave interface. Hasilnya adalah peningkatan throughput sekaligus toleransi terhadap kegagalan salah satu link.

Langkah 1: Membuat Linux Bond

Dari panel navigasi Proxmox, buka System → Network pada node yang dituju. Klik tombol Create lalu pilih Linux Bond.

Isi konfigurasi bonding dengan parameter berikut:
- Name: bond0
- Slaves: ens21 ens22 (pisahkan dengan spasi)
- Mode: balance-rr
- Autostart: aktifkan
Tidak perlu mengisi IP/CIDR di sini karena bond ini akan berfungsi sebagai port untuk bridge, bukan sebagai antarmuka yang berdiri sendiri dengan alamat IP. Klik Create.

Catatan: Jangan assign IP langsung ke bond interface jika bond tersebut akan digunakan sebagai bridge port. IP sebaiknya dilekatkan ke bridge-nya saja, bukan ke slave-nya. Ini menghindari konflik routing dan perilaku yang tidak terduga.

Langkah 2: Apply Configuration

Setelah bond dibuat, Proxmox akan menampilkan notifikasi Pending changes di bagian bawah halaman Network. Ini adalah diff dari file /etc/network/interfaces yang akan diterapkan. Proxmox menggunakan pendekatan ini agar kita bisa review perubahan sebelum diterapkan, sehingga risiko kehilangan koneksi ke node bisa diminimalkan.

Klik tombol Apply Configuration untuk menerapkan perubahan tanpa harus reboot. Proxmox akan memanggil ifupdown2 di balik layar untuk mengaktifkan konfigurasi baru secara live.

Setelah berhasil, bond0 akan muncul di daftar dengan tipe Linux Bond, status Active: No (karena belum ada traffic atau bridge yang menggunakannya), dan kolom Ports/Slaves menampilkan ens21 ens22.

Langkah 3: Membuat Linux Bridge di Atas Bond

Sekarang saatnya membuat bridge yang akan digunakan oleh VM. Klik Create → Linux Bridge, lalu isi dengan konfigurasi berikut:
- Name: vmbr3
- IPv4/CIDR: 192.168.14.31/24 (local)
- Bridge ports: bond0
- Autostart: aktifkan
- VLAN aware: aktifkan
Beberapa poin penting dari konfigurasi ini:
- Gateway tidak diisi. Karena ini bukan interface manajemen utama, gateway tidak diperlukan di sini. Jika diisi sembarangan, bisa menyebabkan konflik default route dengan interface manajemen yang sudah ada.
- VLAN aware diaktifkan. Ini adalah best practice di Proxmox. Dengan VLAN aware bridge, kita bisa mengatur VLAN tag langsung dari konfigurasi VM tanpa perlu membuat bridge terpisah untuk setiap VLAN. Range default VLAN ID yang diizinkan adalah 2-4094.
- Bridge port diisi dengan bond0, bukan NIC fisik langsung. Ini yang membedakan dengan setup sebelumnya. Alih-alih menghubungkan bridge langsung ke NIC, kita melapisinya dengan bond terlebih dahulu sehingga bridge mendapat manfaat dari bonding.
Ringkasan Arsitektur

Setelah semua langkah selesai, arsitektur jaringan pada node rafi1 menjadi seperti ini:
```
ens21 ─┐
       ├─► bond0 (balance-rr) ─► vmbr3 (IP, VLAN aware)
ens22 ─┘
```
VM yang terhubung ke vmbr3 akan menggunakan kedua NIC fisik secara bergantian, sehingga mendapatkan bandwidth yang lebih besar dan tetap terhubung selama salah satu link masih hidup.

Hal yang Perlu Diperhatikan

Balance-rr mendistribusikan paket secara round-robin di level paket, bukan per-flow. Ini bisa menyebabkan paket tiba di tujuan dengan urutan yang tidak sesuai, yang pada beberapa skenario bisa menurunkan performa TCP. Jika switch mendukung LACP, pertimbangkan untuk beralih ke mode 802.3ad dengan hash policy layer2+3 atau layer3+4 agar distribusi traffic lebih stabil dan tidak mengganggu urutan paket.

Selain itu, pastikan kedua NIC slave (ens21 dan ens22) terhubung ke switch yang sama atau trunk yang sama agar bonding bekerja dengan benar. Bonding lintas switch (multi-chassis) membutuhkan konfigurasi tambahan di level switch yang lebih kompleks.

Penutup

Untuk selanjutnya, mungkin saya akan menulis bagaimana setup network bridge tersebut agar support VLAN dengan setup VLAN 20. Kemudian untuk setup Proxmox SDN (menggunakan vxlan). Terakhir, coba aplikasikan network pada lxc dan kvm yang ada. Terima kasih sudah membaca.
May 4, 2026
Seharian Troubleshoot Error I/O di PBS
Hari ini seharusnya cuma setup seperti biasa. Tambah datastore baru di PBS, backing-nya pakai S3 (MinIO lokal), selesai dalam 30 menit. Kenyataannya? Tidaaaaak.

Awal Mulanya Simpel

Setup-nya sebenarnya tidak rumit. Punya PBS jalan di 192.168.14.200, punya MinIO di 192.168.14.100:9000, tinggal mount bucket-nya via s3fs ke /mnt/s3-datastore, lalu daftarkan ke PBS sebagai datastore. Done.

Mount jalan, ls bisa, bahkan touch file ke mount point berhasil dan filenya muncul di MinIO UI. Semua terlihat normal.

Klik Add Datastore di PBS Web UI.
```
TASK ERROR: EIO: I/O error
```
Output:

Investigasi Pertama: Salah Sangka

Pikiran pertama: pasti koneksi ke MinIO bermasalah. Langsung cek, curl ke MinIO health endpoint ok, credential di /root/.passwd-s3fs benar, bucket accessible. Tidak ada yang salah dari sisi network.

Coba via CLI:
```
proxmox-backup-manager datastore create s3-datastore /mnt/s3-datastore \
    --comment "S3 Backup Storage via MinIO"
```
Output:
```
TASK ERROR: EIO: I/O error
```
Sama saja.

Ternyata Write Biasa ≠ Write yang PBS Lakukan

Di sinilah titik yang menarik. touch bisa, buat file bisa, tapi PBS tetap gagal. Setelah lihat lebih dalam, ternyata PBS saat inisialisasi datastore tidak cuma nulis 1 file. Ia langsung buat 256 subdirektori sekaligus di dalam .chunks/ — dari 00/ sampai ff/.

256 mkdir call dalam waktu sangat singkat ke s3fs yang bicara ke MinIO via HTTP. s3fs setiap mkdir = 1 API call. Burst sebesar itu langsung overwhelmed.

Jadi bukan masalah mount, bukan masalah credential, bukan masalah network. Masalahnya adalah PBS terlalu agresif saat init, dan s3fs tidak punya buffer untuk menyerap itu.

Percobaan Pre-create Manual

Ide selanjutnya, kalau PBS yang buat 256 dir sekaligus tidak bisa, buat manual dulu dengan throttle, PBS tinggal pakai strukturnya.
```
mkdir -p /mnt/s3-datastore/.chunks

for i in $(seq 0 255); do
    printf -v hex "%02x" $i
    mkdir -p /mnt/s3-datastore/.chunks/$hex
    sleep 0.2
done
```
Status Sekarang

Sudah jam sore. Mount bersih, MinIO hidup, credential valid, write manual bisa. Tapi PBS masih belum mau terima /mnt/s3-datastore sebagai datastore yang sah.

Troubleshoot masih jalan. Mungkin solusinya di throttle yang lebih lambat, mungkin di ganti s3fs ke rclone yang punya VFS cache layer, mungkin ada hal lain yang belum kelihatan.

Yang jelas, setup yang harusnya 30 menit sudah jalan hampir seharian. Asik.

Akan diupdate kalau sudah ketemu root cause-nya. Kemungkinan bakal pakai rclone daripada s3fs.
April 30, 2026

Komponen	Versi
Kernel module	DRBD 8 ❌
Userspace	DRBD 9 ✔️

Implementasi Proxmox Backup Server pada Proxmox VE

Selamat datang kembali di blog Rafi. Kali ini saya mau sharing pengalaman setup Proxmox Backup Server (PBS) sebagai dedicated backup target untuk cluster Proxmox VE. Kalau kalian udah punya homelab atau production environment berbasis Proxmox, setup PBS ini wajib banget, supaya backup VM kalian lebih terstruktur, deduplicated, dan mudah di-restore.

Di lab saya sendiri, PBS ini dijalankan sebagai VM di atas node Proxmox dengan IP statis 192.168.14.200. Yuk langsung kita mulai dari awal!

Langkah 1 — Buat VM untuk Proxmox Backup Server

Langkah pertama adalah membuat VM baru di Proxmox yang nantinya akan menjalankan PBS. Klik Create VM di Proxmox Web UI.

Tab General

Di tab General, isi konfigurasi berikut:

Node: pve23
VM ID: 200
Name: pbs-rafi-192.168.14.200
Resource Pool: Rafi

Tab OS — Pilih ISO Proxmox Backup Server

Pindah ke tab OS. Di sini kita pilih ISO yang akan dipakai untuk instalasi:

Storage ISO: dataisoonnfs
ISO Image: proxmox-backup-server_4.1-1.iso (1.51 GB)
Guest OS Type: Linux
Version: 6.x – 2.6 Kernel

Spesifikasi VM yang Direkomendasikan

Komponen	Minimum
vCPU	2 core
RAM	4 GB
Disk OS	32 GB
Disk Backup	Sesuai kebutuhan
Network	VirtIO, 1 NIC

Setelah semua tab dikonfigurasi (System, Disks, CPU, Memory, Network), klik Finish lalu boot VM. Proses instalasi PBS berlangsung seperti instalasi Debian biasa, jadi ikuti saja wizard-nya hingga selesai.

Langkah 2 — Buat Datastore di PBS

Login ke https://192.168.14.200:8007
Navigasi ke Datastore → Add Datastore via panel kiri
Isi form Name, Path, GC Schedule via GUI

Verifikasi langsung dari dashboard datastore PBS

Langkah 3 — Daftarkan PBS sebagai Storage di Proxmox VE

PBS sudah siap. Sekarang kita daftarkan PBS ke Proxmox VE cluster agar bisa digunakan sebagai backup target dari semua node.

Navigasi ke Storage di Datacenter

Dari Proxmox Web UI, buka Datacenter → Storage → Add → Proxmox Backup Server.

Isi konfigurasi koneksi ke PBS

Field	Keterangan
ID	Nama storage di Proxmox VE
Server	IP address VM PBS
Username	User PBS (format: user@realm)
Password	Password user PBS
Nodes	Semua node cluster bisa akses
Content	Tipe konten yang disimpan
Datastore	Nama datastore yang dibuat tadi
Namespace	Namespace PBS (default)
Fingerprint	Wajib untuk self-signed cert

Fingerprint: PBS default menggunakan self-signed certificate, sehingga fingerprint wajib diisi. Cara termudah: coba klik Add tanpa fingerprint — Proxmox akan menampilkan fingerprint PBS untuk dikonfirmasi. Copy dan paste ke field Fingerprint.

Best Practice: Jangan gunakan root@pam di environment production. Buat user PBS khusus dengan permission minimal yang diperlukan — misalnya hanya bisa backup dan restore ke datastore tertentu saja. Ini meminimalkan risiko jika credential bocor.

Klik Add dan tunggu Proxmox verifikasi koneksi ke PBS.

Langkah 4 — Verifikasi Integrasi Berhasil

Jika semua langkah berjalan lancar, storage pbs-backup akan muncul di daftar storage Datacenter dengan status Enabled: Yes dan Shared: Yes.

Dari storage list final, terlihat pbs-backup sudah terdaftar dengan type Proxmox Backup Server, content Backup, dan bisa diakses oleh semua node di cluster. Selamat — PBS sudah terintegrasi penuh!

Tabel Perbandingan Backup PBS dengan NFS

Fitur	Backup NFS/Local	Proxmox Backup Server
Deduplication	❌	✅ (chunk-level)
Enkripsi end-to-end	❌	✅
Incremental backup	Terbatas	✅ (via dirty-bitmap)
Verifikasi integritas	❌	✅ (built-in verify job)
Retention management	Manual	✅ (otomatis)
Dedicated Web UI	❌	✅
Backup saat VM running	Tergantung mode	✅ (snapshot mode)

Dengan deduplication, storage yang digunakan jauh lebih efisien. Untuk environment yang punya 5+ VM, PBS benar-benar sangat worth it dibanding backup konvensional ke NFS.

Troubleshooting

“Connection refused” saat add PBS storage
Cek apakah port 8007 di PBS bisa diakses. Coba buka https://192.168.14.200:8007 dari browser. Cek juga firewall di VM PBS.

“Certificate verification failed”
Isi field Fingerprint dengan SHA-256 fingerprint certificate PBS via CLI: proxmox-backup-manager cert info, via GUI: Dashboard -> Button “Show Fingerprint”

Datastore tidak muncul di dropdown
Pastikan username dan password sudah benar. Coba login manual ke web UI PBS dengan credential yang sama untuk verifikasi.

April 29, 2026

Import VM dari VMware ke Proxmox VE
Halo! Jadi begini ceritanya, beberapa waktu lalu saya ada list tugas untuk migrate beberapa VM dari VMware ESXi ke Proxmox. Awalnya saya pikir ini bakal ribet banget, tapi ternyata setelah dicoba, prosesnya cukup mudah kok. Walaupun awalnya saya salah menafsirkan untuk import VM.

Nah, di artikel ini saya mau share cara yang menurut saya paling mudah dan aman untuk import VM dari VMware ke Proxmox. Saya akan fokus ke satu metode saja supaya kalian nggak bingung dengan terlalu banyak pilihan.

Kebutuhan

Sebelum mulai, pastikan kalian sudah punya:
1. Akses ke VMware ESXi/vCenter
  - Username dan password (minimal user biasa, tapi lebih baik root)
  - Bisa login ke web interface
2. Proxmox yang sudah jalan
  - Minimal 1 node (di tutorial ini saya pakai 3 node)
  - Storage dengan space yang cukup
3. Koneksi internet atau network yang stabil
  - Untuk download/transfer file VM
Langkah 1 — Tambahkan Storage ESXi di Datacenter

Masuk ke Datacenter → Storage → Add → ESXi (paling bawah di dropdown).

Masukkan kredensial ESXi kemudian Klik Add. Storage akan otomatis muncul di semua node cluster (VMware (rafi1) dan VMware (rafi2)).

Langkah 2 — Verifikasi Storage Terdaftar

Di sidebar kiri, pastikan sudah muncul:
- VMware (rafi1) — dengan ikon cloud
- VMware (rafi2) — dengan ikon cloud
Klik salah satu, lalu pilih tab Virtual Guests. Kamu akan melihat dua VM yang tersedia dari ESXi:
- ha-datacenter/vmforvmware/Debian12/Debian12.vmx — format vmx
- ha-datacenter/vmforvmware/Talos/Talos.vmx — format vmx
Langkah 3 — Mulai Import VM

Pilih baris VM yang ingin di-import (misal Debian12.vmx), lalu klik tombol Import di atas tabel.

Langkah 4 — Konfigurasi Import Guest

Dialog “Import Guest” akan muncul. Sesuaikan parameter berikut (berdasarkan screenshot kamu):

Best practice: Pilih storage yang mendukung shared storage cluster.

Langkah 5 — Opsi Live Import (Opsional)

Centang Live Import hanya jika VM di ESXi masih dalam keadaan mati (stopped) dan kamu ingin Proxmox menyalakannya di sisi Proxmox sambil disk disalin di background. Untuk migrasi normal, biarkan tidak dicentang.

Langkah 6 — Klik Import dan Monitor Progress

Klik tombol Import. Proxmox akan mulai menyalin disk image dari ESXi via jaringan. Pantau progress di panel Logs di bagian bawah Proxmox GUI.

THE END. Jadi seperti itu untuk import vm dari vmware yang menurut saya cara tercepat.
April 28, 2026
Menambah ZFS Storage ke Proxmox VE
Melanjutkan pembelajaran menjadi Proxmox Engineer cukup menantang, karena memang harus paham, mulai dari networking hingga pengetahuan tentang storage.

Pada artikel kali ini, saya membuat catatan dari pembelajaran yang sudah saya lakukan yaitu menambahkan storage ZFS sebagai datastore. Langsung saja ke langkah-langkahnya…

Kita sudah punya 3 node:
```
rafi1
rafi2
rafi3
```
Dan tujuan kita:
- Setiap node punya ZFS pool dengan nama sama (zfs-pool)
- Storage muncul di Proxmox
- Siap dipakai untuk replication
Kondisi Awal

Dari rafi1, kalian sudah cek disk:
```
lsblk
```
Output:
```
sda   100G  → OS
sdb   20G   → disk tambahan (target ZFS)
```
Artinya:
- sda = jangan disentuh
- sdb = yang baru saja ditambah sebelumnya
Output:

STEP 1 — Buat ZFS Pool di rafi1

Kalian sudah menjalankan:
```
zpool create -f zfs-pool /dev/sdb
```
Lalu cek:
```
zpool status
```
Output:

Ini artinya:
- ZFS berhasil dibuat
- Disk sudah masuk ke pool
- Tidak ada error
STEP 2 — Tambahkan ke Proxmox Storage (rafi1)

Kalian jalankan:
```
pvesm add zfspool zfs-pool \
  --pool zfs-pool \
  --content images,rootdir
```
Cek:
```
pvesm status
```
Output:

Artinya:
- Storage sudah dikenali Proxmox
- Bisa dipakai untuk VM
STEP 3 — Ulangi disetiap node (rafi2)

Di rafi2, kalian jalankan:
```
pvesm status
```
Output:

Catatan:
- ZFS pool itu harus dibuat manual di tiap node
STEP 4 — Ulangi disetiap node (rafi3)

Langkah di rafi3 sama persis:
```
zpool create -f zfs-pool /dev/sdb
pvesm status
```
Output:

STEP 5 — Verifikasi

Dan di tiap node:
```
zpool list
```
Harus sama:

Kesimpulan

Dari screenshot yang kalian kirim, kita bisa tarik kesimpulan:

Yang sudah benar:
- ZFS di rafi1,rafi2,rafi3 sudah dibuat
- Storage sudah terdaftar
- Status sudah active
Insight Penting (ini yang sering bikin bingung)
```
pvesm status = hanya config
zpool status = kondisi real di node
```
Jadi:
- pvesm bisa bilang OK
- Tapi kalau zpool tidak ada → tetap error
Penutup dan Tips Rafi

Dari pengalaman saya, kesalahan paling sering itu:
- Mengira storage sudah siap hanya dari pvesm status
- Padahal ZFS belum dibuat di semua node
Tips dari saya:
- Selalu cek zpool list di setiap node
- Samakan nama pool dari awal
- Gunakan disk yang konsisten (sdb di semua node kalau bisa)
- Jangan campur nama (tank, zfs-pool, dll)
April 27, 2026
Instalasi NFS Server (VM dan ISO) di Proxmox VE
Jadi hari ini saya memulai training proxmox kembali dengan penuh keseriusan dan saya belum memiliki tulisan mengenai pembuatan NFS yang diintegrasi dengan proxmox. Saat saya mencoba cukup mudah dan minim error, karena di proxmox memang dibantu dengan virtualisasi Web UI nya.

Dalam setup virtualisasi, urusan storage sering jadi hal yang “terasa penting” ketika sudah mulai penuh atau ribet dikelola. Awalnya mungkin masih aman pakai storage lokal di Proxmox, tapi begitu VM mulai banyak, ISO numpuk, dan container bertambah, pengelolaan jadi kurang fleksibel. Di titik ini, biasanya kita mulai butuh storage terpusat.

Di lab kali ini, saya coba setup NFS Server dengan OS Debian 12 yang nantinya akan diintegrasikan ke Proxmox VE. Tujuannya simpel: semua disk VM, ISO, dan template LXC disimpan di satu tempat, jadi lebih mudah dikelola dan bisa dipakai bersama.

Konsep Dasar NFS (Network File System)

NFS (Network File System) adalah protokol yang memungkinkan sebuah server membagikan folder ke client melalui jaringan. Jadi dari sisi client (dalam hal ini Proxmox), folder tersebut terasa seperti storage lokal, padahal sebenarnya berada di server lain.

Dalam implementasi Proxmox, NFS biasanya digunakan untuk:
- Menyimpan disk VM
- Menyimpan file ISO
- Menyimpan template LXC
Cara kerjanya:
- Server NFS melakukan export directory
- Proxmox mount directory tersebut sebagai storage
- Semua data diakses lewat jaringan
Kelebihan NFS:
- Setup relatif cepat dan tidak ribet
- Native di Linux (tidak perlu tambahan kompleks)
- Cocok untuk lab dan skala kecil
Kekurangannya:
- Bergantung pada performa jaringan
- Tidak sekuat solusi seperti Ceph untuk high availability
1. Persiapan Server NFS

Spesifikasi:
- OS: Debian 12
- IP Address: 192.168.1.254
- Role: NFS Server
Update sistem:
```
apt update && apt upgrade -y
```
Set hostname:
```
hostnamectl set-hostname nfs.server
```
2. Instalasi NFS Server

Install service NFS:
```
apt install nfs-kernel-server -y
```
Output:

Cek service:
```
systemctl status nfs-server
```
Output:

3. Pembuatan Directory Share

Saya buat dua direktori utama:
- /srv/nfs/vm → untuk disk VM & container
- /srv/nfs/iso → untuk ISO & template
```
mkdir -p /srv/nfs/vm
mkdir -p /srv/nfs/iso
```
Set permission:
```
chown -R nobody:nogroup /srv/nfs
chmod -R 777 /srv/nfs

Note: ⚠️ Untuk production, sebaiknya gunakan permission lebih ketat (misalnya berdasarkan UID/GID Proxmox
```
Output:

4. Konfigurasi Export NFS

Edit file:
```
nano /etc/exports
```
Tambahkan:
```
/srv/nfs/vm 192.168.1.0/24(rw,sync,no_subtree_check,no_root_squash)
/srv/nfs/iso 192.168.1.0/24(rw,sync,no_subtree_check,no_root_squash)
```
Apply konfigurasi:
```
exportfs -a
systemctl restart nfs-server
```
Cek:
```
exportfs -v
```
5. Integrasi NFS ke Proxmox

Masuk ke Web UI Proxmox VE

5.1 Storage ISO & Template
- Datacenter → Storage → Add → NFS
- ID: nfs-iso
- Server: 192.168.1.254
- Export: /srv/nfs/iso
- Content:
  - ISO Image
  - Container Template
5.2 Storage Disk VM
- Datacenter → Storage → Add → NFS
- ID: nfs-vm
- Server: 192.168.1.254
- Export: /srv/nfs/vm
- Content:
  - Disk Image
  - Container
6. Upload ISO dan Template

Setelah storage muncul di Proxmox:
- Upload ISO Alpine di tab ISO Images
- Upload template Debian (.tar.zst) di tab CT Templates
Atau bisa juga download langsung dari repository Proxmox.

8. Verifikasi di Server NFS
```
showmount -e
```
Pastikan ada:
```
ls /srv/nfs/vm
ls /srv/nfs/iso
```
Kesimpulan & Tips Teknis

Setup NFS ini sebenarnya cukup “ringan” tapi impact-nya lumayan terasa, terutama kalau mulai banyak VM atau sering bongkar pasang environment lab. Dengan storage terpusat, kita jadi tidak terlalu bergantung pada disk lokal di Proxmox.

Beberapa hal yang sebaiknya diperhatikan dari pengalaman setup ini:
- Untuk lab, permission 777 masih oke, tapi jangan dipakai di production.
- Usahakan pakai jaringan yang stabil (kalau bisa dipisah khusus storage).
- Performa NFS sangat tergantung network, jadi bottleneck biasanya bukan di server.
- Kalau mulai scale up, bisa pertimbangkan solusi lain seperti distributed storage.
- Backup masih diperlukan, NFS bukan solusi redundancy.
Dengan setup ini, storage Proxmox jadi lebih fleksibel dan enak dipakai untuk eksperimen maupun deployment kecil.
April 23, 2026
Menambahkan OSD Baru dan Mengatur Class SSD/HDD pada Ceph
Hari ini saya mencoba melanjutkan latihan pada cluster Proxmox yang sudah saya bangun sebelumnya. Saya menulis catatan ini karena saya merasa masih perlu banyak latihan dan troubleshooting, terutama pada bagian storage. Saat ini saya memang masih sering menemukan hal-hal yang perlu saya pahami lebih dalam, baik di Nextcloud maupun di Ceph, sehingga saya ingin mendokumentasikan setiap percobaan yang saya lakukan supaya alurnya tidak hilang dan bisa saya pelajari ulang ketika dibutuhkan.

Tujuan percobaan hari ini adalah menambahkan disk baru pada Proxmox, menjadikannya sebagai OSD Ceph, lalu mengatur class storage supaya bisa dibedakan antara SSD dan HDD. Hal ini penting karena di lingkungan storage seperti Ceph, pengelompokan disk berdasarkan class sangat membantu untuk mengatur distribusi data, menentukan pool, dan memisahkan storage yang dipakai untuk kebutuhan cepat dan kebutuhan biasa. Dengan begitu, saya bisa mulai memahami bagaimana Ceph bekerja bukan hanya sebagai storage cluster, tetapi juga sebagai sistem yang mengatur penempatan data berdasarkan aturan tertentu.

1. Mengecek disk baru yang tersedia

Langkah pertama yang saya lakukan adalah memastikan disk baru benar-benar terdeteksi di node. Saya cek dengan lsblk.
```
lsblk | grep sdd
```
Dari hasil pengecekan, disk sdd muncul sebagai disk 20 GB. Ini menandakan bahwa disk tersebut sudah terbaca oleh sistem dan siap untuk dipakai sebagai kandidat OSD.

Pada tahap ini saya hanya memastikan disk baru tersedia dan belum dipakai oleh partisi lama, LVM, atau Ceph. Ini penting karena kalau disk masih memiliki sisa konfigurasi lama, proses pembuatan OSD bisa gagal atau menghasilkan status yang tidak sehat.

2. Membuat OSD baru dari disk tersebut

Setelah yakin disk tersedia, saya langsung mencoba menjadikannya OSD dengan ceph-volume.
```
ceph-volume lvm create --data /dev/sdd
```
Dari output yang muncul, terlihat bahwa physical volume berhasil dibuat di /dev/sdd.

Saya memahami bahwa perintah ini cukup penting karena Ceph akan menangani proses pembuatan LVM dan OSD secara otomatis. Jadi saya tidak perlu membuat PV, VG, atau LV satu per satu secara manual. Dengan ceph-volume, proses pembuatan OSD menjadi lebih singkat dan terstruktur.

3. Mengecek hasil OSD di cluster

Setelah OSD dibuat, saya cek lagi struktur OSD yang ada dengan:
```
ceph osd tree
```
Dari hasil ini saya melihat bahwa OSD baru sudah masuk ke cluster dan statusnya up. Namun, class yang digunakan masih default, yaitu hdd.

Di tahap ini saya membuktikan bahwa OSD baru memang sudah berhasil bergabung ke cluster. Artinya disk baru tidak hanya terbaca di sistem, tetapi juga sudah dikenal oleh Ceph sebagai bagian dari storage cluster.

4. Mencoba mengubah class OSD menjadi SSD

Karena saya ingin mensimulasikan pemisahan storage antara HDD dan SSD, saya mencoba mengubah salah satu OSD menjadi class SSD.
```
ceph osd crush set-device-class ssd osd.3
```
Namun ternyata muncul error bahwa OSD tersebut sudah terikat pada class hdd, sehingga class tidak bisa langsung diganti.

Dari sini saya belajar bahwa Ceph tidak mengizinkan class OSD diubah secara langsung jika OSD tersebut sudah memiliki class sebelumnya. Jadi saya tidak bisa langsung melakukan perubahan dari hdd ke ssd tanpa menghapus class lama terlebih dahulu. Ini cukup penting karena saya sempat mengira class bisa diganti begitu saja.

5. Menghapus class lama terlebih dahulu

Untuk mengatasi error tadi, saya terlebih dahulu menghapus class yang lama.
```
ceph osd crush rm-device-class osd.3
```
Setelah perintah ini dijalankan, Ceph menghapus class yang menempel pada OSD tersebut.

Langkah ini menunjukkan bahwa perubahan class di Ceph harus dilakukan secara berurutan. Saya harus membersihkan label class lama sebelum menetapkan class baru. Jadi alurnya bukan langsung mengganti, tetapi hapus dulu lalu set ulang.

6. Menetapkan class baru menjadi SSD

Setelah class lama dihapus, barulah saya bisa menetapkan class baru untuk osd.3, osd.4 dan osd.5.
```
ceph osd crush set-device-class ssd osd.3
```
Setelah itu saya cek kembali hasilnya dengan ceph osd tree.

Pada titik ini saya berhasil mengubah OSD tersebut menjadi class SSD. Ini penting karena sekarang saya bisa mulai memisahkan storage berdasarkan jenis disk, walaupun di lab ini semua masih berupa simulasi. Hasil akhirnya, di cluster saya ada OSD dengan class HDD dan ada OSD dengan class SSD.

7. Hasil akhir pembagian class OSD

Setelah dicek kembali, hasil akhirnya menjadi seperti ini:
- rafi1
  - osd.0 → hdd
  - osd.3 → ssd
- rafi2
  - osd.2 → hdd
  - osd.4 → ssd
- rafi3
  - osd.1 → hdd
  - osd.5 → ssd
Dari hasil ini saya berhasil membuat simulasi storage tiering sederhana. Dengan adanya pemisahan class, saya bisa melanjutkan ke tahap berikutnya yaitu membuat CRUSH rule dan pool berdasarkan class tersebut. Ini membuka jalan agar saya bisa memisahkan storage cepat dan storage biasa dalam satu cluster Ceph.

Dari percobaan hari ini, saya mendapatkan beberapa poin penting:

Pertama, disk baru harus dipastikan benar-benar terbaca dan bersih sebelum dijadikan OSD. Kedua, ceph-volume sangat membantu karena proses pembuatan OSD bisa dilakukan otomatis. Ketiga, class OSD di Ceph tidak bisa langsung diganti, sehingga saya harus menghapus class lama terlebih dahulu sebelum menetapkan class baru. Keempat, pembagian class seperti SSD dan HDD sangat berguna untuk menyiapkan struktur storage yang lebih rapi dan mudah diatur.

Akhir Kata

Percobaan hari ini membuat saya lebih paham bagaimana Ceph mengelola OSD dan class storage. Walaupun terlihat sederhana, ternyata ada alur yang harus diikuti dengan benar supaya hasilnya sesuai. Saya juga jadi lebih mengerti bahwa Ceph sangat ketat dalam hal metadata storage, terutama saat mengatur device class.

Catatan ini saya buat sebagai dokumentasi pribadi supaya ketika saya mengulang setup ini lagi, saya tidak perlu menebak-nebak dari awal. Ke depannya mungkin saya melanjutkan ke pembuatan CRUSH rule, pool berdasarkan class, lalu menghubungkannya dengan pengujian VM dan storage yang lebih real.
April 14, 2026
Backup File ke PBS Menggunakan proxmox-backup-client
Hari ini saya melanjutkan training Proxmox VE, dan seperti biasa, saya mencoba mensimulasikan skenario yang mendekati kondisi production. Kali ini yang saya uji adalah backup file langsung dari dalam VM menggunakan Proxmox Backup Client, bukan hanya backup VM atau LXC ke PBS seperti biasanya, tapi backup folder spesifik seperti /etc langsung dari dalam sistem operasi guest.

Setup lab saya waktu itu cukup sederhana:
- Cluster Proxmox (nested)
  - https://rafiharlianto.blogspot.com/2026/03/membuat-proxmox-cluster-dengan-3-node.html
- PBS server sudah berjalan
- Salah satu VM menggunakan Ubuntu 24.04
- Target: backup folder /etc ke PBS
Semuanya terlihat lancar sampai saya jalanin perintah ini:

Command:
```
apt install proxmox-backup-client
```
Output nya malah:

Saya sempat bingung. Ini fitur Proxmox, tapi kenapa tidak ada di Ubuntu?

Penyebabnya

Setelah saya telusuri dan tanya-tanya AI, jawabannya ternyata sederhana, “Ubuntu tidak memiliki repository Proxmox secara default.”

Paket proxmox-backup-client memang tidak ada di repo bawaan Ubuntu. Jadi apt tidak tahu harus mengambilnya dari mana. Ini berbeda dengan node Proxmox VE atau PBS yang sudah menyertakan repository mereka sendiri sejak awal instalasi.

Di sinilah saya mulai memahami satu hal yang sebelumnya tidak terlalu saya perhatikan, ekosistem Proxmox tidak bergantung pada repository Ubuntu atau Debian standar. Proxmox punya repository sendiri, dan kalau kita ingin menggunakan tool seperti Proxmox Backup Client di luar ekosistem itu, kita harus menambahkan repository-nya secara manual.

Langkah-langkah

Berikut cara yang saya gunakan sampai akhirnya berhasil:

1. Tambahkan repository Proxmox Backup Client
```
echo "deb http://download.proxmox.com/debian/pbs-client bookworm main" > /etc/apt/trusted.gpg.d/pbs-client.list
```
2. Tambahkan GPG key
```
wget https://enterprise.proxmox.com/debian/proxmox-release-bookworm.gpg -O /etc/apt/trusted.gpg.d/proxmox-release.gpg
```
3. Update package list
```
apt update
```
4. Install ulang
```
apt install proxmox-backup-client
```
Setelah itu, instalasi berjalan tanpa error. Verifikasi dengan menjalankan:
```
proxmox-backup-client version
```
Output versi muncul — client sudah siap digunakan.

Percobaan Backup

Kemudian saya langsung jalankan backup folder /etc dengan command:
```
proxmox-backup-client backup etc.pxar:/etc --repository pvebackup@pbs@192.168.X.X:pbsstore
```
Hasilnya: backup berhasil, file muncul di datastore PBS, dan bisa dilihat langsung dari web UI. Persis seperti yang diharapkan.

Catatan

Pertama, soal repository. Ubuntu 24.04, meskipun sudah modern, tidak secara otomatis menyertakan paket-paket dari ekosistem Proxmox. Kita perlu menambahkan repository-nya sendiri.

Kedua, soal versi codename. Harus menggunakan bookworm karena Proxmox berbasis Debian Bookworm, dan repository PBS Client pun mengikuti codename yang sama. Ini penting agar tidak terjadi konflik dependensi.

Ketiga, dan ini yang paling saya highlight, error ini bukan sesuatu yang salah. Ini normal, dan banyak orang yang baru masuk ke dunia Proxmox pasti akan menemuinya.

Akhir Kata Rafi

Dari uji coba hari ini, saya jadi lebih paham bahwa belajar Proxmox bukan hanya tentang virtualisasi atau manajemen VM. Ada sisi ekosistem yang perlu dipahami juga, mulai dari bagaimana repository-nya bekerja, sampai bagaimana tool seperti PBS Client berinteraksi dengan sistem operasi guest.

Seharusnya sih saya menulis tentang cara pembuatan PBS dulu ya. Tapi tidak apa lah ini untuk catatan saya untuk kedepannya. Kalau kalian sedang di tahap yang sama, sedang mengeksplorasi PBS dan ingin mencoba backup client langsung dari dalam VM — kemungkinan besar kamu juga akan menemui error yang sama. Semoga tulisan ini bisa menghemat waktu yang biasanya habis untuk trial and error.
April 13, 2026