Tag: proxmox

  • Memahami Kelebihan Proxmox ARM64 untuk Homelab

    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:

    HardwareStatus
    NVIDIA Grace / VeraOfficially Supported
    UEFI ARM ServerBest Effort
    Raspberry PiTidak 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:

    KelebihanManfaat untuk Homelab
    Efisiensi dayaCocok untuk server 24/7
    Hardware compactHomelab lebih kecil
    Proxmox full featureTetap dapat KVM, LXC, cluster, HA
    ZFS & CephStorage tetap fleksibel
    ARM ecosystemBanyak pilihan hardware baru
    Virtualisasi ARMCocok untuk Kubernetes dan Linux
    Management samaTidak 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

  • Hasil Deploy VM Ubuntu di Proxmox dengan Terraform

    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.

    HostnameFungsiIP Address
    terraform-controllerMenjalankan Terraform192.168.14.80
    ubuntu-tf-01VM hasil Terraform192.168.14.81
    ubuntu-tf-02VM hasil Terraform192.168.14.82
    ubuntu-tf-03VM hasil Terraform192.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:

    1. Mengunduh Ubuntu 24.04 Cloud Image.
    2. Mengimport image ke storage Proxmox.
    3. Membuat tiga VM.
    4. Membuat disk dari Ubuntu Cloud Image.
    5. Mengatur CPU, RAM, disk, dan network.
    6. Mengatur IP statis melalui Cloud-init.
    7. Memasukkan SSH public key.
    8. 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:

    ResourceJumlah
    Ubuntu Cloud Image1
    VM Ubuntu3

    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

  • Mengintegrasikan Proxmox dengan Terraform untuk Deploy Virtual Machine

    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.

    HostnameFungsiIP Address
    terraform-controllerTerraform Controller192.168.14.80
    ubuntu-tf-01VM Target192.168.14.81
    ubuntu-tf-02VM Target192.168.14.82
    ubuntu-tf-03VM Target192.168.14.83

    Konfigurasi Proxmox:

    ParameterNilai
    Nodepverafi1
    APIhttps://192.168.14.31:8006/
    Gateway192.168.14.31
    Bridgevmbr0
    Image Storagelocal
    VM Storagelocal-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:

    ResourceKonfigurasi
    CPU2 Core
    RAM2 GB
    Disk20 GB
    Networkvmbr0
    IP192.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:

    ParameterNilai
    Userterraform@pve
    Token IDprovider
    Privilege SeparationNonaktif

    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:

    VMVM IDIPCPURAMDisk
    ubuntu-tf-01181192.168.14.812 Core2 GB20 GB
    ubuntu-tf-02182192.168.14.822 Core2 GB20 GB
    ubuntu-tf-03183192.168.14.832 Core2 GB20 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:

    ResourceJumlah
    Ubuntu Cloud Image1
    Ubuntu VM3
    Total4

    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
  • Memilih Storage Proxmox Sesuai Kebutuhan: Homelab hingga Production

    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:

    PertimbanganVariabel
    Jumlah nodeSingle node, cluster kecil, atau cluster besar.
    Jenis workloadVM pengujian, file server, database, atau layanan production.
    AvailabilityLayanan harus tetap berjalan saat node gagal.
    PerformaApakah workload membutuhkan IOPS atau throughput tinggi.
    PengelolaanSeberapa kompleks storage yang mampu kita rawat.
    BackupBagaimana 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

    SkenarioPilihan awal
    Homelab single nodeDirectory, LVM-thin, atau ZFS
    Homelab dengan fokus integritas dataZFS
    Cluster kecil 2–3 nodeZFS Replication atau shared NFS
    Sudah memiliki NAS/SANNFS atau iSCSI
    Production multi-node dengan HACeph
    Backup VM dan containerProxmox Backup Server
    Backup di lokasi lainPBS 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
  • Jumlah RAM untuk Homelab Proxmox

    Jumlah RAM untuk Homelab Proxmox

    Saat membangun homelab menggunakan Proxmox VE, salah satu pertanyaan yang paling sering muncul adalah, seberapa besar RAM yang sebenarnya dibutuhkan? Tidak sedikit yang langsung membeli RAM sebanyak mungkin karena menganggap virtualisasi selalu membutuhkan memori besar. Padahal, kebutuhan RAM sangat bergantung pada jumlah virtual machine (VM), container (LXC), dan layanan yang akan dijalankan.

    Di sisi lain, memilih kapasitas RAM yang terlalu kecil juga bisa menjadi masalah. Host Proxmox akan kehabisan memori lebih cepat, performa VM menurun, bahkan proses backup atau migrasi bisa terasa lambat. Oleh karena itu, sebelum membeli atau meng-upgrade server homelab, ada baiknya memahami kebutuhan RAM sesuai dengan skenario penggunaan.

    Pada artikel ini kita akan membahas rekomendasi kapasitas RAM untuk homelab Proxmox, mulai dari kebutuhan dasar hingga homelab yang digunakan untuk belajar clustering, Kubernetes, maupun Ceph.


    RAM Penting untuk Proxmox

    Berbeda dengan CPU yang dapat dibagi (oversubscribe) kepada banyak VM, RAM merupakan resource yang jauh lebih terbatas. Ketika sebuah VM diberikan RAM sebesar 4 GB, maka Proxmox harus menyediakan alokasi tersebut agar VM dapat berjalan dengan baik.

    Semakin banyak VM yang aktif, semakin besar pula kebutuhan RAM pada host.

    Sebagai gambaran sederhana:

    • Host Proxmox sendiri membutuhkan sekitar 2–4 GB RAM agar berjalan dengan lancar dan aman.
    • Setiap VM memiliki kebutuhan RAM masing-masing.
    • LXC Container biasanya lebih hemat RAM dibandingkan VM.
    • ZFS juga menggunakan RAM sebagai cache (ARC) untuk meningkatkan performa storage.

    Artinya, jangan hanya menghitung RAM berdasarkan jumlah VM saja. Sisakan juga ruang untuk sistem operasi host dan kebutuhan storage.


    Faktor yang Mempengaruhi Kebutuhan RAM

    Sebelum menentukan kapasitas RAM, perhatikan beberapa hal berikut.

    1. Jumlah Virtual Machine

    Semakin banyak VM yang dijalankan secara bersamaan, semakin besar RAM yang dibutuhkan.

    Contohnya:

    • Ubuntu Server : 1–2 GB
    • Debian Server : 512 MB–1 GB
    • Windows Server : 4–8 GB
    • Windows 11 : 4–8 GB
    • Kubernetes Node : 2–4 GB
    • Docker Host : 2–4 GB

    Jika Anda memiliki lima VM yang masing-masing membutuhkan 2 GB, maka setidaknya diperlukan sekitar 10 GB RAM hanya untuk VM tersebut.


    2. Menggunakan VM atau LXC?

    LXC jauh lebih ringan dibandingkan VM karena berbagi kernel dengan host.

    Sebagai contoh:

    • Pi-hole
    • Nginx
    • AdGuard Home
    • Grafana
    • Prometheus
    • Jellyfin

    Semua layanan tersebut sangat cocok dijalankan menggunakan LXC sehingga konsumsi RAM menjadi lebih kecil.


    3. File System yang Digunakan

    Apabila menggunakan ZFS, sebaiknya sediakan RAM lebih banyak karena ZFS memanfaatkan memori sebagai cache.

    Walaupun aturan lama menyebutkan “1 GB RAM untuk setiap 1 TB storage”, pada penggunaan homelab modern aturan tersebut sudah tidak lagi menjadi keharusan. Namun, tetap disarankan memiliki RAM yang cukup agar performa ZFS tetap optimal.


    Rekomendasi RAM Berdasarkan Skenario

    8 GB RAM

    Kapasitas ini cocok apabila Anda baru mulai belajar Proxmox.

    Contoh penggunaan:

    • 1–2 VM Linux
    • Beberapa LXC
    • DNS Server
    • Nginx
    • Pi-hole
    • Monitoring sederhana

    Kelebihan:

    • Biaya murah
    • Cocok untuk belajar virtualisasi dasar

    Kekurangan:

    • Sulit menjalankan Windows dan banyak VM secara bersamaan.
    • Ruang untuk pengembangan cukup terbatas.

    16 GB RAM

    Menurut saya, ini merupakan kapasitas yang paling ideal untuk sebagian besar homelab.

    Dengan RAM 16 GB, Anda sudah bisa menjalankan:

    • Active Directory
    • Windows Server
    • Ubuntu Server
    • Docker
    • GitLab
    • Monitoring
    • Reverse Proxy
    • Beberapa LXC

    Masih tersedia ruang untuk melakukan eksperimen tanpa terlalu cepat kehabisan memori.


    32 GB RAM

    Jika homelab mulai digunakan untuk simulasi lingkungan produksi, 32 GB menjadi pilihan yang jauh lebih nyaman.

    Contoh workload:

    • Kubernetes
    • Docker Swarm
    • Beberapa Windows Server
    • Database
    • Monitoring lengkap
    • CI/CD
    • Cluster Proxmox kecil

    Pada kapasitas ini Anda tidak perlu terlalu sering mematikan VM hanya untuk mencoba layanan baru.


    64 GB atau Lebih

    Kapasitas ini lebih cocok untuk pengguna yang ingin membangun homelab tingkat lanjut.

    Misalnya:

    • Cluster Proxmox 3 Node
    • Ceph Storage
    • Kubernetes Multi Node
    • OpenStack
    • OpenShift
    • Banyak VM aktif secara bersamaan

    Jika homelab digunakan sebagai lab sertifikasi atau simulasi data center, kapasitas ini akan memberikan ruang yang jauh lebih lega.


    Ingat RAM untuk Host

    Kesalahan yang sering dilakukan adalah mengalokasikan seluruh RAM kepada VM.

    Sebaiknya sisakan RAM untuk:

    • Proxmox VE
    • ZFS ARC
    • Backup
    • Live Migration
    • Proses update
    • Operasi sistem lainnya

    Sebagai contoh, apabila server memiliki RAM 32 GB, hindari memberikan seluruh kapasitas tersebut kepada VM. Sisakan beberapa gigabyte agar host tetap responsif.


    Mengaktifkan Memory Ballooning

    Proxmox menyediakan fitur Memory Ballooning yang memungkinkan penggunaan RAM menjadi lebih efisien.

    Fitur ini cocok apabila:

    • Tidak semua VM aktif menggunakan RAM secara maksimal.
    • Ingin meningkatkan kepadatan VM pada satu host.
    • Menjalankan banyak server Linux dengan beban yang berubah-ubah.

    Namun, untuk VM dengan beban kerja berat seperti database atau aplikasi yang membutuhkan performa stabil, sebaiknya tetap gunakan alokasi RAM tetap (fixed memory).


    RAM untuk Homelab

    Sebelum membeli RAM, pertimbangkan beberapa hal berikut:

    • Pilih motherboard yang masih memiliki slot RAM kosong agar mudah melakukan upgrade.
    • Gunakan dua keping RAM (dual-channel) jika memungkinkan untuk performa yang lebih baik.
    • Prioritaskan kapasitas dibandingkan kecepatan RAM jika anggaran terbatas.
    • Jika berencana menggunakan ZFS, Kubernetes, atau Ceph, pertimbangkan langsung memulai dari 32 GB.

    Kesimpulan

    Tidak ada jawaban pasti mengenai berapa RAM yang dibutuhkan untuk homelab Proxmox karena semuanya bergantung pada workload yang akan dijalankan. Namun, sebagai acuan sederhana:

    Kapasitas RAMCocok Untuk
    8 GBBelajar Proxmox dan menjalankan beberapa VM Linux atau LXC.
    16 GBHomelab rumahan dengan beberapa VM dan layanan sehari-hari.
    32 GBKubernetes, Docker, monitoring, database, dan simulasi lingkungan produksi.
    64 GB+Cluster Proxmox, Ceph, virtualisasi skala besar, serta lab sertifikasi.

    Apabila Anda baru membangun homelab, saya menyarankan minimal menggunakan RAM 16 GB. Kapasitas tersebut sudah cukup fleksibel untuk menjalankan beberapa VM sekaligus tanpa cepat kehabisan memori. Jika suatu saat kebutuhan meningkat, Anda tinggal menambah RAM tanpa harus mengganti seluruh platform.

    Dengan perencanaan RAM yang tepat sejak awal, homelab Proxmox akan lebih nyaman digunakan untuk belajar, melakukan pengujian, maupun membangun berbagai layanan virtual di rumah.


    Referensi

  • 9 Panduan Cleanup Resource Proxmox VE Secara Berkala

    9 Panduan Cleanup Resource Proxmox VE Secara Berkala

    Seiring bertambahnya jumlah VM, container, backup, dan file ISO, resource pada Proxmox VE juga akan semakin banyak. Kalau tidak pernah dirapikan, lama-kelamaan storage menjadi penuh, tampilan Web GUI semakin berantakan, dan proses administrasi kurang efisien.

    Pada artikel ini saya akan merangkum beberapa panduan cleanup yang dapat dilakukan secara berkala berdasarkan pembahasan dari VirtualizationHowTo. Sebagian besar langkah dapat dilakukan langsung melalui GUI Proxmox VE, sehingga tidak perlu selalu menggunakan terminal.


    1. Hapus File ISO yang Sudah Tidak Digunakan

    Setelah selesai menginstal sistem operasi, file ISO biasanya tetap tersimpan di storage. Jika dibiarkan terus, ukurannya bisa mencapai puluhan gigabyte tanpa disadari.

    Cara melalui Web GUI

    1. Login ke Proxmox Web UI.
    2. Pilih salah satu node Proxmox.
    3. Pilih storage yang menyimpan ISO (pada contoh nfs-iso).
    4. Buka tab ISO Images.

    Di halaman ini akan terlihat seluruh file ISO yang tersimpan.

    Jika ada ISO yang sudah tidak diperlukan:

    • Pilih file ISO.
    • Klik Remove.
    • Konfirmasi penghapusan.

    Sebaiknya simpan hanya ISO yang masih sering digunakan agar storage tetap lega.


    2. Hapus Template VM yang Sudah Tidak Digunakan

    Template VM sangat membantu untuk deployment cepat. Namun setelah beberapa tahun, biasanya template lama tetap tersimpan walaupun sudah tidak pernah dipakai.

    Cara melalui Web GUI

    1. Pilih node Proxmox.
    2. Cari VM yang memiliki ikon Template.
    3. Pastikan template tersebut memang sudah tidak digunakan.
    4. Klik More.
    5. Pilih Remove.

    Misalnya kalian memiliki:

    • Ubuntu 20.04 Template
    • Ubuntu 22.04 Template
    • Ubuntu 24.04 Template

    Jika seluruh deployment sudah menggunakan Ubuntu 24.04, template lama dapat dipertimbangkan untuk dihapus.


    3. Bersihkan Template LXC Lama

    Selain template VM, Proxmox juga menyediakan template untuk LXC Container. Jika sudah tidak digunakan lagi, template tersebut juga sebaiknya dibersihkan.

    Cara melalui Web GUI

    1. Klik Datacenter.
    2. Pilih Storage.
    3. Klik storage yang digunakan (biasanya local).
    4. Buka tab CT Templates.

    Pilih template yang sudah tidak digunakan kemudian klik Remove.


    4. Hapus Snapshot VM dan LXC yang Sudah Tidak Digunakan

    Snapshot biasanya dibuat sebelum upgrade, patching, atau perubahan konfigurasi. Namun setelah proses maintenance selesai dan server dipastikan berjalan normal, snapshot sering kali lupa dihapus.

    Padahal snapshot yang dibiarkan terlalu lama dapat:

    • menggunakan storage lebih banyak,
    • memperbesar ukuran virtual disk,
    • memperlama proses backup.

    Cara melalui Web GUI

    1. Pilih VM atau Container.
    2. Masuk ke tab Snapshots.
    3. Pilih snapshot yang sudah tidak diperlukan.
    4. Klik Delete.

    Saya sendiri biasanya hanya menyimpan snapshot selama proses maintenance berlangsung. Setelah semuanya dipastikan normal, snapshot langsung saya hapus.


    5. Hapus File Backup Lama

    Backup memang penting, tetapi backup yang tidak pernah dibersihkan hanya akan memenuhi storage. Jika belum menggunakan retention policy, sebaiknya lakukan pengecekan secara berkala.

    Cara melalui Web GUI

    1. Klik Datacenter.
    2. Pilih Backups.

    Jika ada backup yang sudah tidak diperlukan:

    • Pilih file backup.
    • Klik Remove.

    Lebih baik lagi jika kalian mengatur retention policy sehingga backup lama dapat dihapus secara otomatis.


    6. Hapus Kernel Proxmox Lama

    Setelah beberapa kali melakukan update Proxmox VE, biasanya kernel lama masih tetap tersimpan.

    Kernel lama memang berguna sebagai cadangan apabila terjadi masalah setelah update. Namun jika jumlahnya terlalu banyak, ruang pada partisi sistem juga akan semakin berkurang.

    Melihat daftar kernel yang terpasang

    Jalankan perintah berikut:

    proxmox-boot-tool kernel list

    Contoh output:

    6.17.13-19-pve
    7.0.0-3-pve
    7.0.14-6-pve

    Untuk mengetahui kernel yang sedang digunakan saat ini, jalankan:

    uname -r

    Output:

    7.0.0-3-pve

    Artinya server saat ini sedang menggunakan kernel tersebut.

    Menghapus kernel lama

    Jika sudah yakin server berjalan stabil menggunakan kernel terbaru, kernel lama dapat dihapus menggunakan package manager Debian.

    Misalnya:

    apt purge proxmox-kernel-6.17.13-19-pve

    Setelah selesai, jalankan:

    apt autoremove

    untuk menghapus dependency yang sudah tidak digunakan.

    Tips: Jangan langsung menghapus semua kernel lama. Sebaiknya sisakan kernel yang sedang aktif dan minimal satu kernel versi sebelumnya sebagai cadangan jika suatu saat perlu melakukan rollback setelah update.


    7. Bersihkan Orphaned Disk Setelah Menghapus VM

    Kadang sebuah VM sudah dihapus, tetapi virtual disk masih tertinggal pada storage. Hal ini biasanya terjadi setelah proses restore, migrasi, atau perubahan konfigurasi disk.

    Cara melalui Web GUI

    1. Pilih VM.
    2. Masuk ke tab Hardware.

    Jika terdapat item seperti:

    • Unused Disk 0
    • Unused Disk 1

    berarti disk tersebut sudah tidak terhubung ke VM.

    Untuk menghapusnya:

    1. Pilih Unused Disk.
    2. Klik Remove.

    Langkah sederhana ini dapat menghemat cukup banyak kapasitas storage.


    8. Audit VM dan Container yang Sudah Tidak Digunakan

    Banyak administrator memiliki VM seperti:

    • testing
    • lab
    • migration
    • temporary
    • old-server

    yang sebenarnya sudah tidak pernah digunakan lagi.

    Selain memenuhi storage, daftar VM juga menjadi kurang rapi.

    Via Web GUI

    1. Periksa seluruh daftar VM dan Container.
    2. Cari VM yang sudah lama berstatus Stopped.
    3. Pastikan tidak ada pengguna yang masih memerlukannya.
    4. Klik More.
    5. Pilih Remove.

    Sebelum menghapus VM, pastikan kalian sudah memiliki backup apabila sewaktu-waktu masih diperlukan.


    9. Hapus Storage Mount Point yang Sudah Tidak Digunakan

    Kadang sebuah storage NFS, SMB, iSCSI, atau direktori lokal sudah tidak digunakan lagi tetapi masih terdaftar pada Proxmox.

    Selain membuat tampilan kurang rapi, storage yang tidak aktif juga dapat memunculkan notifikasi error apabila mount point sudah tidak tersedia.

    Cara melalui Web GUI

    1. Klik Datacenter.
    2. Pilih Storage.
    3. Pilih storage yang sudah tidak digunakan.
    4. Klik Remove.

    Sebelum menghapus storage, pastikan:

    • tidak ada VM yang masih menggunakan storage tersebut,
    • tidak ada backup yang tersimpan,
    • tidak ada ISO atau template penting yang masih berada di dalamnya.

    Tips Tambahan

    Selain sembilan cleanup di atas, saya biasanya juga melakukan beberapa pengecekan sederhana setelah maintenance:

    • Memastikan seluruh job backup berhasil.
    • Mengecek kapasitas storage pada setiap datastore.
    • Memastikan seluruh node cluster berstatus Online.
    • Memeriksa notifikasi warning atau error pada Datacenter.
    • Jika menggunakan Ceph, pastikan status cluster dalam kondisi HEALTH_OK.

    Walaupun tidak termasuk bagian dari artikel sumber, langkah-langkah tersebut cukup membantu untuk memastikan kondisi Proxmox tetap sehat setelah proses cleanup selesai.


    Penutup

    Cleanup pada Proxmox VE sering kali dianggap pekerjaan kecil karena tidak berdampak langsung terhadap performa VM. Padahal, jika dilakukan secara rutin, cleanup dapat menjaga storage tetap lega, membuat tampilan Web GUI lebih rapi, dan memudahkan administrator ketika mengelola infrastruktur virtualisasi.

    Dari sembilan panduan di atas, hampir seluruhnya dapat dilakukan langsung melalui Web GUI tanpa harus membuka terminal. Hanya penghapusan kernel lama yang saat ini masih memerlukan akses CLI.


    Referensi

  • Mengenal Proxmox Offline Mirror

    Tidak semua server Proxmox boleh menyentuh internet. Di banyak lingkungan enterprise, host virtualisasi ditaruh di segmen tertutup atau benar-benar air-gapped, sementara update tetap harus jalan. Untuk kasus seperti ini Proxmox punya tool resmi bernama Proxmox Offline Mirror (POM). Di tulisan ini saya bahas konsepnya saja, belum ke langkah teknisnya.

    Apa itu Proxmox Offline Mirror

    POM adalah tool untuk membuat dan mengelola mirror repository APT Proxmox dan Debian secara lokal. Dari mirror lokal itu, isinya bisa diekspor ke media eksternal seperti flashdisk, hardisk portabel, atau network share, lalu dipakai untuk update sistem yang tidak punya akses internet. Selain repository, POM juga bisa mengelola subscription key untuk host offline, jadi aktivasi lisensi tetap bisa dilakukan tanpa host tersebut terhubung ke internet.

    Yang sering salah dipahami: POM tidak dipasang di host Proxmox yang offline. POM dipasang di mesin terpisah yang punya koneksi internet, bisa Debian polos atau host Proxmox lain. Host offline hanya jadi konsumen dari media yang sudah disiapkan.

    Dua binary di dalamnya

    BinaryDijalankan diFungsi
    proxmox-offline-mirrorHost mirror (online)Membuat dan mengelola mirror serta media
    proxmox-offline-mirror-helperHost target (offline)Memakai media dan mengaktifkan subscription di PVE, PBS, atau PMG

    Empat istilah yang perlu dipahami

    IstilahPenjelasan
    keysSubscription key, baik untuk sistem mirror itu sendiri maupun untuk host offline
    mirrorsMetadata repository upstream plus path lokal tempat snapshot disimpan
    snapshotsPotret repository pada satu titik waktu
    mediaLokasi filesystem (flashdisk atau network share) tempat mirror disinkronkan

    Cara kerjanya

    Alurnya kurang lebih begini:

    1. Host mirror menarik isi repository upstream, lalu menyimpannya sebagai snapshot.
    2. Snapshot yang dipilih disinkronkan ke sebuah medium.
    3. Medium dibawa ke host offline, dicolok atau diekspos lewat jaringan internal (NFS, CIFS/SMB, atau HTTP).
    4. Host offline mengarahkan APT ke medium tersebut, lalu update seperti biasa.

    Bagian yang menarik ada di penyimpanannya. POM menyimpan file berdasarkan checksum di sebuah pool, lalu membuat hardlink ke file tersebut. Efeknya, snapshot kedua dan seterusnya tidak menduplikasi paket yang tidak berubah, jadi punya banyak snapshot tidak berarti disk membengkak berkali lipat. Satu base directory juga bisa dipakai bersama beberapa mirror, dan untuk repository Proxmox memang disarankan pakai satu base directory saja supaya dedup-nya maksimal.

    Konsekuensinya, filesystem yang dipakai wajib mendukung hardlink, di host mirror maupun di medium. Filesystem turunan Windows seperti FAT tidak mendukung ini, jadi flashdisk bawaan pabrik biasanya perlu diformat ulang ke ext4 atau XFS.

    Kenapa pakai POM, bukan rsync biasa

    Mirror repository sebetulnya bisa dibuat manual dengan rsync atau apt-mirror. Bedanya, POM memberi beberapa hal yang relevan untuk lingkungan produksi:

    • Snapshot berbasis waktu. Update jadi terkontrol karena kalian tahu persis versi paket mana yang dikirim ke host offline, dan bisa rollback ke snapshot sebelumnya.
    • Hemat disk. Deduplikasi lewat hardlink pool, bukan salin ulang.
    • Verifikasi bawaan. Signature repository ikut diverifikasi saat sync.
    • Filter scope. Arsitektur, komponen, nama paket, dan section bisa dipersempit supaya mirror tidak menarik hal yang tidak dibutuhkan, misalnya paket debug symbol.
    • Manajemen subscription offline. Ini yang tidak bisa dilakukan tool mirror generik.

    Catatan sebelum mencoba

    Beberapa hal yang perlu disiapkan:

    • Storage cukup besar. Untuk mirror Debian dan Proxmox VE dasar, Proxmox menyarankan minimal 150 GiB.
    • Host mirror berbasis Debian, CPU 64bit, idealnya 2 core atau lebih.
    • Untuk mirror repository enterprise, dibutuhkan subscription produk yang aktif sekaligus subscription POM sendiri. Kalau lab kalian pakai repo no-subscription, alurnya lebih sederhana dan tanpa key sama sekali.

    Penutup

    Intinya POM memindahkan beban koneksi internet dari host produksi ke satu mesin mirror. Host Proxmox tetap bisa dipatch rutin walaupun berada di jaringan tertutup. Untuk langkah instalasi dan konfigurasinya saya bahas terpisah di tulisan berikutnya. Semoga bermanfaat.

    Referensi

  • Mengaktifkan Repository Debug Symbol (dbgsym) di Proxmox VE 9

    Mengaktifkan Repository Debug Symbol (dbgsym) di Proxmox VE 9

    Proxmox baru saja merilis repository khusus untuk paket debug symbol di https://dbgsym.proxmox.com/. Paket -dbgsym berisi informasi debug untuk paket binary pasangannya, berguna saat kalian perlu menganalisis crash atau hang dengan tools seperti gdb, systemd-coredump, atau crash. Repository ini berlaku untuk Proxmox VE, PBS, PMG, dan PDM berbasis Debian 12 (Bookworm) dan Debian 13 (Trixie). Di panduan ini saya contohkan implementasi dan pengujiannya di Proxmox VE 9 (Trixie).

    Informasi Lab

    ItemKeterangan
    ProdukProxmox VE 9 (Debian 13 Trixie)
    Nodepverafi1
    Aksesroot via SSH atau shell web UI
    KebutuhanKoneksi internet ke dbgsym.proxmox.com

    Catatan: paket dbgsym bersifat inert (tidak mempengaruhi operasi normal), jadi aman dipasang di sistem production maupun test. Repository ini juga publik, tidak ada pembedaan enterprise atau no-subscription.

    1. Menambahkan Repository dbgsym

    Buat file repository dalam format deb822 di /etc/apt/sources.list.d/pve-dbgsym.sources:

    cat > /etc/apt/sources.list.d/pve-dbgsym.sources << 'EOF'
    Types: deb
    URIs: https://dbgsym.proxmox.com/debian/pve
    Suites: trixie
    Components: pve-dbgsym
    Signed-By: /usr/share/keyrings/proxmox-archive-keyring.gpg
    EOF

    Jika memakai versi lain, sesuaikan bagian produk pada URI dan component (pbs, pmg, pdm) serta suite (bookworm untuk Debian 12).

    Update index paket:

    apt update

    Pastikan repository baru ikut ter-fetch. Di output apt update harus muncul baris dari dbgsym.proxmox.com, kurang lebih seperti ini:

    Get: https://dbgsym.proxmox.com/debian/pve trixie InRelease

    Bisa juga dicek lewat:

    apt policy | grep dbgsym

    2. Melihat Paket dbgsym yang Tersedia

    Cek daftar paket debug symbol yang bisa dipasang:

    apt list 2>/dev/null | grep dbgsym | head -20

    Kalian akan melihat paket seperti pve-qemu-kvm-dbgsym, pve-manager-dbgsym, dan sebagainya.

    3. Instalasi Paket dbgsym

    Install paket dbgsym yang cocok dengan binary yang ingin kalian debug. Contoh untuk QEMU:

    apt install pve-qemu-kvm-dbgsym gdb -y

    Install gdb untuk pengujian di langkah berikutnya.

    Verifikasi file debug sudah masuk ke /usr/lib/debug:

    dpkg -L pve-qemu-kvm-dbgsym | head

    Output harus menunjukkan file di bawah /usr/lib/debug/.build-id/.

    4. Verifikasi Pasangan Build ID

    Setiap binary Linux modern punya identitas unik (build ID) yang dipakai gdb untuk mencari file debug pasangannya secara otomatis. Ambil build ID dari binary QEMU:

    readelf -n /usr/bin/qemu-system-x86_64 | grep "Build ID"

    Contoh output:

    Build ID: 1d5ac8f0a05d7978645a38aaeac6cd9e6f32e539

    Cocokkan nilai ini dengan nama file di /usr/lib/debug/.build-id/ (dua karakter pertama jadi nama folder, sisanya jadi nama file .debug):

    ls /usr/lib/debug/.build-id/1d/

    Kalau muncul file 5ac8f0a05d7978645a38aaeac6cd9e6f32e539.debug, berarti file debug untuk binary tersebut sudah lengkap dan siap dipakai gdb. Kalau tidak ada, berarti versi paket binary dan dbgsym tidak sinkron (lihat troubleshooting).

    Catatan: pengecekan dengan gdb -batch -ex quit <binary> sering dipakai sebagai tes cepat, tapi pesan Reading symbols from ... tidak selalu tampil di mode batch meskipun symbol sudah terbaca dengan benar. Jadi verifikasi build-id di atas lebih bisa diandalkan daripada mengandalkan ada tidaknya pesan tersebut.

    5. Pengujian dengan Proses Live

    Cara paling meyakinkan untuk membuktikan debug symbol benar-benar berfungsi adalah attach gdb ke proses QEMU yang sedang berjalan, tanpa mematikannya. VM akan freeze sesaat selama gdb attach, jadi gunakan VM test, bukan VM production.

    Cari PID proses QEMU untuk VM tertentu. Proxmox menyimpan PID di /var/run/qemu-server/<VMID>.pid:

    cat /var/run/qemu-server/<VMID>.pid

    Attach gdb ke PID tersebut, ambil backtrace semua thread, lalu langsung lepas:

    gdb -batch -p <PID> -ex "thread apply all bt" -ex detach -ex quit

    Kalau debug symbol berfungsi, backtrace akan menunjukkan nama fungsi dan lokasi source, bukan alamat mentah. Contoh potongan hasil pengujian saya di thread utama QEMU:

    Thread 1 (Thread ... "kvm"):
    #5  qemu_poll_ns (fds=<optimized out>, nfds=<optimized out>, timeout=<optimized out>) at ../util/qemu-timer.c:343
    #6  0x... in os_host_main_loop_wait (timeout=989602) at ../util/main-loop.c:308
    #7  main_loop_wait (nonblocking=nonblocking@entry=0) at ../util/main-loop.c:592
    #8  0x... in qemu_main_loop () at ../system/runstate.c:946
    #9  0x... in qemu_default_main (opaque=opaque@entry=0x0) at ../system/main.c:50
    #10 0x... in main (argc=<optimized out>, argv=<optimized out>) at ../system/main.c:93
    [Inferior 1 (process ...) detached]

    Dua hal yang wajar muncul di output dan bukan tanda gagal:

    • Baris ?? () from /lib/x86_64-linux-gnu/libc.so.6: berasal dari glibc, di luar cakupan paket pve-qemu-kvm-dbgsym. Kalau mau symbol glibc ikut terbaca, perlu paket debug terpisah dari Debian (libc6-dbg).
    • Thread seperti kvm-nx-lpage-re atau iou-wrk-* yang menunjukkan Cannot access memory at address 0x0: ini kernel worker thread, gdb memang tidak bisa unwind stack userspace untuk thread jenis ini.

    Troubleshooting

    GejalaPenyebabSolusi
    apt update error 404 di repo dbgsymSuite atau produk di file .sources tidak sesuaiCocokkan suite (trixie/bookworm) dan produk (pve/pbs/pmg/pdm) dengan sistem kalian
    Error NO_PUBKEY atau signatureFile keyring tidak adaPastikan paket proxmox-archive-keyring terpasang: apt install proxmox-archive-keyring
    gdb tetap bilang no debugging symbolsVersi paket binary dan dbgsym tidak samaJalankan apt update && apt upgrade agar versi keduanya sinkron, lalu install ulang paket dbgsym
    Dulu install debug package dari repo standar, sekarang tidak dapat updatePaket dbgsym sudah dipindah ke repo terpisahTambahkan repository dbgsym seperti langkah 1

    Penutup

    Dengan repository ini, kalian tidak perlu lagi mencari paket debug di repo standar saat menganalisis crash di Proxmox. Semoga bermanfaat.

    Referensi

  • Turnkey di Proxmox: 100+ Appliance Siap Pakai

    Turnkey di Proxmox: 100+ Appliance Siap Pakai

    Hari ini saya baca-baca artikel di Virtualization Howto, salah satu blog yang cukup sering saya buka kalau cari tahu update terbaru tentang proxmox maupu virtualisasi. Ada satu tulisan yang baru yaitu tentang pembahasan soal fitur Proxmox yang menyediakan lebih dari 100 TurnKey Linux appliance.

    Yang bikin saya penasaran istilah turnkey di lxc proxmox. Jadi tulisan adalah untuk memahami lebih lanjut turnkey yang ada di proxmox, plus bagian kapan kalian sebaiknya pakai appliance turnkey dan kapan lebih baik pakai Docker saja.

    Turnkey itu istilah, bukan nama produk

    Ini yang sempat bikin saya bingung di awal. Turnkey adalah istilah umum, bukan merek. Asalnya dari frasa turn the key, seperti mobil yang tinggal putar kunci lalu jalan. Kalian tidak perlu merakit mesinnya dulu.

    Di dunia IT, turnkey solution berarti sistem yang sudah dirakit, dikonfigurasi, dan diuji oleh pihak lain, lalu diserahkan ke kalian dalam kondisi siap dipakai. Lawan katanya adalah build it yourself, di mana kalian install OS kosong, pasang web server, database, aplikasi, dan sambungkan semuanya sendiri.

    Di konteks virtualisasi, wujud turnkey biasanya adalah virtual appliance: satu image VM atau container yang di dalamnya sudah berisi OS plus aplikasi yang sudah dikonfigurasi. Kalian tinggal import, nyalakan, isi password, selesai.

    Nah, kebetulan ada proyek yang namanya persis seperti istilahnya, yaitu TurnKey Linux. Di sinilah kebingungan saya berasal.

    TurnKey Linux, proyeknya

    TurnKey Linux adalah proyek yang membuat kumpulan appliance siap pakai berbasis Debian. Satu appliance berisi satu aplikasi lengkap dengan semua dependensinya yang sudah dikonfigurasi.

    Beberapa hal yang perlu kalian tahu soal proyek ini:

    • Basisnya Debian standar, bukan distro eksotis. Jadi apt, systemd, dan struktur direktorinya tetap seperti Debian yang kalian kenal.
    • Tersedia dalam banyak format: ISO, image VM, dan yang paling relevan buat kita, template LXC yang langsung didukung Proxmox.
    • Ada wizard inisialisasi yang jalan saat pertama kali login, meminta root password, password admin aplikasi, dan alamat email untuk notifikasi.
    • Tiap appliance biasanya membawa confconsole (menu konfigurasi berbasis teks, termasuk untuk request sertifikat Let’s Encrypt) dan panel web administrasi. Port panelnya berbeda-beda tergantung appliance, jadi cek langsung di layar setelah boot.

    Di Proxmox, ini bukan fitur baru

    Poin yang diangkat artikel tadi memang tepat: template TurnKey ini bukan fitur baru, hanya jarang dilirik. Kebanyakan orang buka menu CT Templates, lihat debian-12-standard, ambil itu, lalu tutup jendelanya. Padahal di bawahnya ada ratusan baris lagi.

    Kalian bisa cek sendiri dari shell node Proxmox:

    pveam update
    pveam available | grep turnkey
    

    Atau kalau mau lebih rapi, filter langsung per section:

    pveam available --section turnkeylinux
    

    Daftarnya panjang sekali. Untuk gambaran, ini sebagian kategori yang tersedia:

    KategoriContoh appliance
    DatabasePostgreSQL, MySQL, MongoDB, Redis, CouchDB
    File dan syncFile Server (Samba), Nextcloud, Syncthing
    Jaringan dan VPNWireGuard, OpenVPN, OpenLDAP
    DevOpsGitea, GitLab, Jenkins, Ansible
    Framework aplikasiDjango, Laravel, Rails, Node.js, ASP.NET Core, Symfony, Tomcat
    BisnisOdoo, SuiteCRM, EspoCRM, Mattermost, Snipe-IT, Invoice Ninja, Leantime

    Yang menarik dari artikel sumbernya, penulisnya menyoroti appliance File Server. Begitu container dinyalakan, kalian langsung disambut setup Samba, bukan disuruh install dan konfigurasi smb.conf dari nol.

    Cara memakainya

    Lewat GUI, jalurnya seperti ini:

    1. Pilih node, lalu masuk ke storage local.
    2. Buka tab CT Templates, klik Templates.
    3. Ketik turnkey di kolom pencarian, pilih appliance yang kalian mau, klik Download.
    4. Klik Create CT, dan di tab Template pilih file yang barusan diunduh.

    Lewat CLI, unduhnya begini. Salin nama template persis dari output pveam available, karena nomor versinya berubah seiring rilis:

    pveam download local debian-12-turnkey-gitea_18.1-1_amd64.tar.gz
    

    Setelah container jalan, login ke konsolnya. Wizard inisialisasi akan meminta password dan beberapa isian dasar, lalu aplikasinya sudah siap diakses.

    Kelebihan appliance turnkey

    Saya lihat nilainya ada di beberapa hal berikut:

    • Cepat sekali. Dari nol sampai aplikasi jalan bisa di bawah lima menit, dibanding satu jam kalau kalian rakit sendiri.
    • Konfigurasinya sudah masuk akal. Web server, database, dan koneksi antar keduanya sudah disiapkan orang yang paham aplikasinya.
    • Basis Debian yang familiar. Kalau ada yang perlu diubah, kalian masuk saja dan edit seperti biasa. Tidak ada abstraksi aneh yang harus dipelajari dulu.
    • Ringan karena LXC. Bukan full VM, jadi overhead-nya kecil dan cocok buat homelab dengan RAM terbatas.
    • Bagus untuk belajar. Ini yang sering diremehkan. Kalian bisa masuk ke appliance yang sudah jadi dan lihat bagaimana orang lain menyusun konfigurasinya. Itu bahan belajar yang bagus.
    • Backup dan snapshot Proxmox tetap berlaku. Karena ini container biasa, vzdump dan snapshot jalan normal.

    Kekurangan yang perlu kalian sadari

    Artikel sumbernya tidak banyak membahas sisi ini, jadi bagian berikut lebih ke pertimbangan saya sendiri.

    • Kalian mewarisi keputusan orang lain. Konfigurasinya sudah jadi, tapi kalian tidak otomatis tahu apa saja yang diubah dari default. Untuk lab tidak masalah. Untuk produksi, kalian tetap harus audit isinya.
    • Versi aplikasi menempel ke rilis appliance. Update aplikasi tidak selalu mengikuti rilis upstream secepat yang kalian mau, karena tergantung maintainer appliance-nya.
    • Upgrade major itu merepotkan. Umumnya polanya bukan upgrade di tempat, melainkan bikin container baru lalu migrasi data. Ini beban yang perlu diperhitungkan sejak awal.
    • Satu appliance satu aplikasi. Sepuluh aplikasi berarti sepuluh container dengan sepuluh OS yang harus kalian patch dan pantau masing-masing.
    • Tidak declarative. Tidak ada file yang bisa kalian commit ke git. Kalau container ini hilang, kalian mengulang wizard dan konfigurasi manual lagi, tanpa jejak yang bisa direproduksi.
    • Kalau ujungnya kalian kustomisasi berat, keuntungannya habis. Begitu kalian ganti banyak hal di dalamnya, kalian sebenarnya sudah kembali ke mode rakit sendiri, tapi dengan titik awal yang tidak kalian dokumentasikan.

    Turnkey atau Docker?

    Sebelum masuk tabel, ada satu hal yang perlu diluruskan. Keduanya sebenarnya menjawab masalah di lapisan yang berbeda.

    Appliance turnkey menjawab “tolong siapkan mesin lengkap untuk saya”. Hasilnya satu sistem operasi utuh dengan systemd, cron, dan banyak service di dalamnya. Docker menjawab “tolong jalankan proses ini dengan dependensi yang tetap”. Hasilnya unit yang lebih kecil, sekali pakai, dan definisinya tertulis dalam file.

    Jadi pertanyaannya bukan mana yang lebih bagus, tapi kebutuhan kalian sedang di lapisan yang mana.

    Perbandingan karakteristik

    AspekTurnKey (LXC appliance)Docker
    Waktu setup awalSangat cepat, wizard interaktifCepat kalau compose file sudah ada
    Bentuk konfigurasiManual di dalam containerTertulis di docker-compose.yml
    ReproducibilityRendah, sulit diulang persisTinggi, tinggal jalankan ulang file yang sama
    Update aplikasiIkut rilis applianceGanti tag image, biasanya lebih dekat ke upstream
    Beban perawatanSatu OS penuh per aplikasiSatu host OS untuk banyak aplikasi
    Cocok untuk CI/CDLemahKuat, memang dirancang untuk itu
    Aplikasi multi-service legacyNyaman, karena ada systemdSering perlu akal-akalan

    Tabel pemilihan

    Ini bagian yang paling praktis. Cari baris yang paling mirip situasi kalian.

    Situasi kalianPilihAlasan
    Mau coba software baru, belum tahu bakal dipakai atau tidakTurnKeyLima menit siap, kalau tidak cocok tinggal hapus container
    Layanan produksi jangka panjangDockerUpdate dan rollback lebih terkendali
    Konfigurasi harus tercatat di git (IaC atau GitOps)DockerCompose file bisa di-commit, appliance tidak
    Demo ke klien atau bahan training, harus cepat siapTurnKeyTampil jadi tanpa waktu persiapan panjang
    Butuh stack lengkap tapi malas meracik sendiriTurnKeyWeb server dan database sudah disambungkan
    Ada pipeline CI/CD yang rebuild otomatisDockerAppliance tidak punya jalur otomatisasi ke arah ini
    Banyak aplikasi menumpuk di satu hostDockerTidak perlu merawat OS terpisah untuk tiap aplikasi
    Aplikasi legacy yang butuh systemd dan banyak serviceTurnKeyLXC memang perilakunya seperti VM kecil
    Lab sementara yang minggu depan dihapusTurnKeyUmurnya pendek, tidak perlu investasi konfigurasi
    Orang lain harus bisa reproduce environment kalianDockerCukup kirim satu file, hasilnya sama
    Mau update aplikasi mengikuti upstream secepatnyaDockerTidak menunggu rilis appliance
    Kalian sedang belajar dan ingin lihat konfigurasi yang benarTurnKeyBisa dibongkar isinya sebagai bahan belajar

    Pola yang muncul kira-kira begini. Kalau umur layanannya pendek dan yang kalian butuhkan adalah kecepatan, pilih TurnKey. Kalau umurnya panjang dan yang kalian butuhkan adalah kontrol serta pengulangan, pilih Docker.

    Penulis artikel sumbernya sampai di kesimpulan yang sama. Untuk layanan jangka panjang, Docker tetap menang di tempatnya karena jauh lebih enak diotomatisasi. TurnKey dia pakai untuk evaluasi software, belajar platform baru, proof of concept, dan environment sementara.

    Kesimpulan

    Saya senang akhirnya duduk dan memastikan arti istilah turnkey, karena ternyata konsepnya sederhana: sistem yang sudah dirakitkan orang lain sampai tinggal pakai. Dan template TurnKey Linux di Proxmox memang layak dilirik, terutama karena sudah ada di depan mata tanpa perlu install apa-apa lagi.

    Buat saya posisinya jelas. TurnKey itu alat untuk mempercepat fase mencoba, bukan pengganti Docker untuk layanan yang kalian rawat bertahun-tahun. Lain kali kalau kalian penasaran dengan software baru dan malas menyiapkan lab-nya, coba dulu pveam available | grep turnkey sebelum buka dokumentasi instalasi manual. Lumayan menghemat sore.

    Referensi

  • Latihan Troubleshooting dengan Claude Code

    Latihan Troubleshooting dengan Claude Code

    Jadi hari ini saya mencoba mengasah kemampuan troubleshooting, khususnya pada aplikasi yang dapat diimplementasikan secara on-premise seperti mail server (Zimbra dan Carbonio), platform virtualisasi (Proxmox VE), serta file management (Nextcloud). Menurut saya, kemampuan troubleshooting adalah salah satu keterampilan yang harus terus diasah karena sangat dibutuhkan saat mengelola infrastruktur. Namun, ada satu hal yang sampai sekarang masih sering membuat saya bingung ketika ingin belajar troubleshooting, diantara lain:

    • Saya gonta-ganti konfigurasinya sendiri (oprek)
    • Menunggu ada update/patch/bug terbaru
    • atau, menunggu aplikasi failure/error dengan sendirinya

    Kalau oprek sendiri dengan skill teknis minim seperti saya malah-malah merembet kemana-mana, kalau menunggu update bisa berbulan-bulan, dan apalagi kalau nunggu aplikasi failure nanti malah tidak latihan.

    Masalahnya, menunggu insiden itu tidak efisien. Jadi saya balik logikanya. Saya menjadikan Claude Code untuk merusak lab saya sendiri dengan pola yang realistis, lalu saya yang mendiagnosis dan memperbaiki. Anggap saja latihan tanding, tapi lawannya adalah AI yang paham error apa saja yang biasa terjadi di Proxmox, Nextcloud, Zimbra, atau Carbonio.

    Konsepnya

    Aturannya cuma satu yang penting: Claude berperan sebagai fasilitator, bukan tukang benerin. Tugas dia merusak, memberi gejala, dan memberi petunjuk kalau saya mentok. Yang mendiagnosis dan memperbaiki tetap saya.

    Alurnya kira-kira begini:

    1. Saya pilih platform dan level kesulitan.
    2. Claude menyuntikkan satu fault via SSH, tanpa memberi tahu apa yang dia rusak. (sebenernya mau pake MCP tapi belum paham)
    3. Saya cuma dikasih gejala, seperti tiket dari user. Misalnya “email keluar nyangkut sejak pagi”.
    4. Saya investigasi sendiri. Kalau mentok, boleh minta hint, tapi skornya berkurang.
    5. Setelah saya bilang selesai, Claude verifikasi dan kasih skor.

    Kuncinya ada di poin ketiga. Saya tidak dikasih tahu root cause-nya. Persis seperti simulasi production, saya cuma pegang gejala dan harus menelusuri sendiri sampai ke akar.

    Level 1 sampai 5

    Biar latihannya naik kelas, saya bagi lima level. Makin tinggi, makin dekat ke insiden produksi yang sebenarnya.

    LevelKarakter faultContoh
    1Satu masalah jelas, error terang di logService ke-stop, typo di config
    2Satu masalah, gejala kurang gamblangPort diblok firewall, cert expired
    3Gejala tak langsung lewat dependensiLDAP mati bikin semua auth gagal
    4Cascading, satu akar banyak gejalaDisk penuh, quorum cluster hilang
    5Beberapa masalah sekaligus, butuh metodeFault kombinasi lintas layer

    Level 1 itu pemanasan. Level 5 memaksa saya berpikir sistematis, memisahkan gejala satu per satu, dan menahan diri dari asumsi buru-buru.

    Penutup: Backup, backup, backup

    Sengaja merusak sistem tetap butuh rem. Ada dua aturan yang dibutuhkan

    • Pertama, backup atau snapshot dulu sebelum apa pun.
    • Kedua, kunci jawaban terpisah di folder sementara. Kalau saya baca duluan, latihan jadi percuma. Biar disiplin aja.

    Latihan ini akan dijalankan besok. Stay tune!