Rafi Harlianto

Informatics Engineering

Author: Rafi Harlianto

  • Error auth_supported saat Integrasi Ceph dengan CloudStack

    Error auth_supported saat Integrasi Ceph dengan CloudStack

    Saya sedang menguji integrasi Ceph untuk dijadikan sebagai Primary Storage Apache CloudStack. Ceph disini saya menggunakan Ceph yang diinstall pada Proxmox VE. Pengujian dilakukan dengan konfigurasi berikut:

    KomponenIPVersi
    Management dan KVM192.168.14.8CloudStack 4.23, Rocky Linux 9.8, libvirt 11.10.0
    Proxmox Ceph192.168.14.4Squid 19.2.6

    Client Ceph pada host KVM kemudian diperbarui ke 19.2.6 untuk mendukung kunci aes256k. Catatan rilis resmi Ceph menjelaskan bahwa tipe kunci tersebut diperkenalkan pada rilis ini dan client perlu diperbarui agar dapat menggunakannya. [Baca: ceph.io]

    Kendala

    Setelah pembaruan, pengujian rbd ls berhasil dengan exit code 0. Artinya, operasi listing RBD berhasil menggunakan konfigurasi dan kredensial pada pengujian tersebut. Namun, saat menambahkan Primary Storage melalui CloudStack, prosesnya tetap gagal.

    Penelusuran menemukan bahwa backend storage RBD libvirt 11.10.0 masih mengirim opsi auth_supported, sedangkan library Ceph yang digunakan menolak opsi tersebut. Masalah ini juga dilaporkan pada issue libvirt #918, yang membahas kegagalan storage pool dengan librados 19.2.6 dan 20.2.4. GitLab

    Keberhasilan rbd ls belum membuktikan bahwa seluruh jalur integrasi sudah kompatibel. Penambahan storage melalui CloudStack melibatkan backend RBD libvirt, yang masih gagal ketika menyetel opsi autentikasi ke librados.

    Pengecekan Log

    Log journal libvirtd:

    Oct 06 20:11:22 cs01.lab.internal libvirtd[30048]: internal error: failed to set RADOS option: auth_supported
Oct 06 20:11:58 cs01.lab.internal libvirtd[30048]: internal error: failed to set RADOS option: auth_supported
Oct 06 20:12:16 cs01.lab.internal libvirtd[30048]: internal error: failed to set RADOS option: auth_supported

    Log dari /var/log/cloudstack/agent/agent.log:

    2026-10-06 20:11:22,669 ERROR [kvm.storage.LibvirtStorageAdaptor] (AgentRequest-Handler-1:[]) (logid:2944b393) Failed to create RBD storage pool: org.libvirt.LibvirtException: internal error: failed to set RADOS option: auth_supported
2026-10-06 20:11:58,072 ERROR [kvm.storage.LibvirtStorageAdaptor] (AgentRequest-Handler-2:[]) (logid:2c9bcf38) Failed to create RBD storage pool: org.libvirt.LibvirtException: internal error: failed to set RADOS option: auth_supported
2026-10-06 20:12:16,544 ERROR [kvm.storage.LibvirtStorageAdaptor] (AgentRequest-Handler-5:[]) (logid:522e490d) Failed to create RBD storage pool: org.libvirt.LibvirtException: internal error: failed to set RADOS option: auth_supported

    Ketiga percobaan menghasilkan error yang sama: libvirt gagal menyetel opsi RADOS auth_supported saat membuat storage pool.

    Kasus serupa tercatat pada Apache CloudStack issue #13989. Laporan tersebut menggunakan CloudStack 4.22.1.1 dan Ceph Tentacle 20.2.4, sehingga menjadi pembanding dengan pesan error yang sama, sementara lab saya menggunakan CloudStack 4.23 dan Ceph Squid 19.2.6. GitHub

    Solusi

    Saya kemudian bertanya ke AI dengan memberikan detail infrastruktur, versi paket, hasil pengujian rbd ls, dan log error. AI menyarankan langkah berikut:

    1. Memperbarui libvirt ke paket yang memuat perbaikan terkait, atau melakukan backport patch pada backend RBD libvirt agar menggunakan auth_client_required sebagai pengganti auth_supported.
    2. Setelah perubahan diterapkan, melakukan restart libvirt dan CloudStack Agent.
    3. Mencoba kembali penambahan Primary Storage melalui CloudStack.

    Arah saran dari dokumentasi resmi Ceph menjelaskan opsi auth_client_required. Namun, diskusi patch pada mailing list resmi libvirt juga membahas penggunaan ketiga opsi auth_cluster_required, auth_service_required, dan auth_client_required untuk mempertahankan kondisi sebelumnya. Detail patch yang sesuai masih perlu dicari tahu lebih lanjut. Ceph Documentation

    Sampai catatan ini ditulis, solusi belum saya terapkan dan akan diuji coba kembali pada artikel selanjutnya. Hasil baru sebatas rbd ls tanpa error dan temuan error auth_supported saat penambahan Primary Storage.

  • Delisting IP dari Blacklist s5h.net

    Delisting IP dari Blacklist s5h.net

    Jika IP publik mail server masuk blacklist s5h.net, kita bisa mengajukan penghapusan melalui situs usenix.org.uk. Tersedia dua cara: delisting otomatis dari IP yang terdaftar dan pengajuan manual melalui form.

    Sebelum mengajukan delisting, pastikan sumber spam sudah dihentikan dan masalah keamanan sudah ditangani agar IP tidak kembali masuk blacklist.

    1. Delisting Otomatis

    Cara ini dilakukan dengan mengakses halaman removal dari IP publik yang masuk blacklist.

    1. Login melalui SSH ke server yang koneksi keluarnya menggunakan IP tersebut.
    2. Jalankan perintah berikut untuk IPv4:curl -4 http://www.usenix.org.uk/content/rblremove
    3. Baca respons yang muncul. Menurut dokumentasi s5h.net, IP dapat langsung dihapus jika permintaan berasal dari IP yang terdaftar.
    4. Periksa kembali status blacklist setelah proses selesai.

    Halaman tersebut juga bisa dibuka melalui browser, asalkan koneksinya berasal dari IP yang ingin dihapus. Tidak ada form yang perlu diisi pada metode ini.

    Catatan NAT/VIP: pastikan IP sumber koneksi HTTP keluar sama dengan IP yang masuk blacklist. Membuka halaman dari laptop atau server dengan IP keluar berbeda tidak menghapus IP tujuan. Jika tidak bisa menggunakan IP tersebut untuk koneksi keluar, lanjutkan melalui form manual.

    2. Delisting Manual melalui Form

    Buka halaman Removal Help, lalu isi kolom berikut:

    KolomKeterangan pengisian
    Your email addressAlamat email aktif yang bisa menerima konfirmasi dan pertanyaan dari pengelola.
    Your email address (repeated)Ulangi alamat email yang sama.
    IP address you wish to remove (try the netmask too)IP publik yang ingin dihapus dari blacklist; sertakan netmask jika relevan.
    Reason for delistAlasan mengajukan penghapusan IP.
    What you’ve done to correct the issueTindakan yang benar-benar sudah dilakukan untuk mengatasi penyebab blacklist.
    Why are you unable to use the automatic systemAlasan metode otomatis tidak dapat digunakan.

    Gunakan bahasa Inggris untuk kolom penjelasan, kemudian klik Submit.

    Setelah itu, periksa email konfirmasi dan ikuti tautan validasinya. Jika muncul pesan “Your request is validated”, berarti permintaan sudah tervalidasi, bukan bukti bahwa IP sudah dihapus.

    Pada halaman konfirmasi, pengelola menyebutkan penghapusan dilakukan dalam 36 jam apabila tidak ada keberatan dari admin. Form bantuan juga mengingatkan bahwa respons manual bisa memerlukan beberapa hari, jadi tetap periksa status blacklist untuk memastikan hasil akhirnya.

    Dokumentasi Asli: Dokumentasi s5h.net — How do I delist.

  • Cara Snapshot dan Rollback LVM Thin /opt

    Cara Snapshot dan Rollback LVM Thin /opt

    Hari ini saya melakukan percobaan snapshot dan rollback lvm thin yang sebelumnya pernah saya buat. Panduan ini melanjutkan penggunaan thin LV vgthin/opt yang sudah terpasang di /opt melalui fstab. Pengujian dilakukan pada VM lab dengan file penanda dan seluruh aplikasi Carbonio. Jalankan sebagai root.

    Rollback mengembalikan seluruh isi /opt, sehingga perubahan setelah snapshot akan hilang. Snapshot ikut terhapus setelah merge. Snapshot ini tidak mencakup database atau konfigurasi Carbonio yang berada di luar /opt.

    1. Siapkan pengujian

    Periksa mount dan kapasitas pool:

    findmnt --mountpoint /opt
lvs vgthin

    Pastikan /opt berasal dari vgthin/opt dan Data%/Meta% pada pool belum mendekati penuh.

    Saya juga memasang Carbonio pada Ubuntu 24.04 pada lvmthin /opt untuk menguji pada aplikasi sebenarnya, hentikan service terlebih dahulu selama pengujian:

    systemctl stop carbonio.target

    Layanan lain yang memakai /opt juga harus dihentikan. VM tetap berjalan.

    2. Buat snapshot

    Buat file penanda, lepas filesystem agar snapshot diambil dalam keadaan bersih, lalu buat snapshot:

    mkdir -p /opt/lvmthin-uji
printf 'sebelum snapshot\n' > /opt/lvmthin-uji/status.txt
cd /
umount /opt
lvcreate --snapshot -n opt-snap-uji vgthin/opt
mount /opt

    Jika umount gagal, jangan lanjutkan. Gunakan fuser -vm /opt untuk menemukan proses yang masih mengaksesnya. Hentikan proses tersebut dengan benar; jangan paksa unmount.

    Thin snapshot memakai pool yang sama, jadi tidak perlu opsi ukuran -L atau -V. Gunakan nama snapshot yang belum ada.

    3. Ubah file untuk simulasi

    printf 'sesudah snapshot\n' > /opt/lvmthin-uji/status.txt
cat /opt/lvmthin-uji/status.txt

    File sekarang berisi sesudah snapshot. Layanan aplikasi tetap dihentikan sampai pengujian selesai.

    4. Rollback ke snapshot

    Pastikan snapshot belum di-mount di tempat lain, lalu jalankan:

    cd /
umount /opt
lvchange -an vgthin/opt
lvconvert --mergethin vgthin/opt-snap-uji

    Lanjutkan hanya jika unmount, deaktivasi LV, dan merge berhasil. Jika merge tertunda karena LV masih terbuka, selesaikan akses/mount yang tersisa sebelum melanjutkan.

    Aktifkan LV dan pasang kembali:

    lvchange -ay vgthin/opt
mount /opt
cat /opt/lvmthin-uji/status.txt
lvs vgthin

    File harus kembali berisi sebelum snapshot dan opt-snap-uji sudah tidak ada. Jika Carbonio tadi dihentikan, setelah mount berhasil hidupkan kembali:

    systemctl start carbonio.target

    Uji ini membuktikan rollback filesystem. Pemulihan Carbonio secara utuh memerlukan penyelarasan data aplikasi di luar /opt.

  • Mengenal Migrasi VMware ke CloudStack dan KVM

    Mengenal Migrasi VMware ke CloudStack dan KVM

    Setelah VMware diakuisisi Broadcom, model lisensinya mengalami perubahan dari perpetual atau sekali beli menjadi berlangganan. Perubahan ini menjadi salah satu pertimbangan untuk mengevaluasi biaya dan kelanjutan penggunaan VMware.

    Dari sini, saya pun ditugaskan dan memahami alternatif migrasi menggunakan Apache CloudStack dan KVM. Sebagai referensi, saya membaca VMware-to-CloudStack Migration Guide dari ShapeBlue untuk memahami bagaimana VM yang sudah ada di VMware dapat dipindahkan.

    Konsep

    CloudStack berfungsi sebagai platform pengelola infrastruktur, sedangkan KVM menjadi hypervisor yang menjalankan VM. Proses konversinya dibantu oleh virt-v2v, yang menyesuaikan disk dan sistem operasi dari lingkungan VMware agar dapat berjalan di KVM.

    Jadi, VM yang sebelumnya berjalan pada ESXi akan dipindahkan ke host KVM, kemudian dikelola melalui CloudStack. Sistem operasi dan aplikasi di dalamnya ikut dibawa, tetapi hasilnya tetap perlu diuji.

    Persiapan sebelum migrasi

    Sebelum migrasi, beberapa hal berikut perlu disiapkan:

    • Catat spesifikasi VM: CPU, RAM, disk, sistem operasi, dan IP.
    • Periksa hubungan dan koneksi antar-VM.
    • Pastikan akses ke vCenter, ESXi, dan storage tersedia.
    • Siapkan virt-v2v pada host KVM serta driver VirtIO untuk konversi Windows.
    • Buat backup, tentukan jadwal downtime, dan siapkan langkah rollback.

    Di sisi CloudStack, persiapannya meliputi:

    • Zone, Pod, dan Cluster: lokasi penempatan VM tujuan.
    • Host KVM: pastikan aktif, enabled, dan resource mencukupi.
    • Storage: sediakan ruang untuk disk VM dan proses konversi.
    • Domain dan Account: tentukan pemilik VM.
    • Compute Offering: sesuaikan alokasi CPU dan RAM.
    • Guest Network: siapkan jaringan serta pemetaan IP, gateway, dan VLAN.
    • Disk Offering: siapkan jika diperlukan untuk kebutuhan disk tambahan

    Alur migrasi VM

    Pada alur dasar yang dijelaskan dalam panduan, prosesnya seperti berikut:

    1. Hubungkan CloudStack ke vCenter untuk menampilkan daftar VM.
    2. Pilih VM, kemudian tentukan cluster KVM, account, resource, dan jaringan tujuan.
    3. Ekspor file VM ke storage sementara.
    4. Jalankan konversi menggunakan virt-v2v.
    5. Impor hasil konversi menjadi instance CloudStack.
    6. Periksa VM dan aplikasi sebelum mengalihkan layanan.

    Proses tersebut mencakup penyesuaian driver agar guest dapat berjalan pada perangkat virtual KVM. Untuk Windows, driver VirtIO perlu tersedia pada host yang melakukan konversi.

    Konfigurasi jaringan tetap perlu diperhatikan. IP, gateway, DNS, VLAN, maupun aturan firewall harus disesuaikan dengan desain lingkungan tujuan.

    Hal yang perlu diperhatikan

    Untuk perencanaan awal, siapkan downtime dan matikan VM secara normal sebelum migrasi. Windows wajib dalam kondisi mati. Linux dapat diimpor saat menyala, tetapi hasilnya bersifat crash-consistent sehingga konsistensi data aplikasi tidak terjamin. docs.cloudstack.apache.org

    Migrasi sebaiknya dimulai dari VM development atau layanan yang tidak kritis. Dari pengujian tersebut, kita bisa melihat waktu yang dibutuhkan dan kendala yang muncul sebelum melanjutkan ke production.

    Setelah impor selesai, periksa apakah VM dapat boot, seluruh disk terbaca, jaringan terhubung, dan aplikasi berjalan dengan data yang sesuai. Backup serta langkah rollback juga perlu disiapkan. VM sumber sebaiknya tetap disimpan selama masa validasi, dengan pengaturan agar tidak terjadi konflik IP dengan VM tujuan.

    Referensi: VMware-to-CloudStack Migration Guide — ShapeBlue.

  • Alur Membuat Bundel Apache CloudStack Offline dengan Repo Lokal

    Alur Membuat Bundel Apache CloudStack Offline dengan Repo Lokal

    Saya ingin menyiapkan Apache CloudStack 4.23 di Rocky Linux 9 agar bisa dipasang tanpa internet. CloudStack Management Server dan host KVM nantinya berjalan pada satu mesin yang sama. Disk System VM harus memakai storage lokal mesin tersebut.

    Sebelum masuk ke perintah instalasi, saya membagi pekerjaannya menjadi dua: membuat bundel di VM staging yang masih online, lalu menguji pemasangannya pada satu node Rocky yang offline.

    1. Siapkan VM untuk membuat bundel

    VM Rocky Linux 9 yang sudah ada dipakai sebagai staging. Di sinilah paket dan image dikumpulkan. Pertama, tentukan versi Rocky 9 yang akan dipakai di server target, lalu samakan versi minor dan arsitekturnya dengan staging. Perbarui VM staging, reboot, dan pastikan ruang disk cukup untuk menyimpan bahan instalasi sekaligus file .tgz hasilnya.

    Staging memerlukan akses internet untuk mengambil paket. CloudStack dan KVM tidak perlu dipasang di VM staging, karena mesin ini hanya menyiapkan berkas. Nested virtualization juga belum diperlukan pada tahap ini.

    2. Kumpulkan bahan instalasi offline

    Bahan utamanya adalah isi Rocky Linux 9 DVD ISO, paket CloudStack Management dan KVM agent beserta dependensinya, template System VM untuk KVM, serta satu template guest untuk uji pembuatan VM.

    Paket Rocky dan CloudStack disusun menjadi repository lokal. Dengan begitu, saat bundel dipindahkan, server target bisa memasang paket dari berkas sendiri tanpa menghubungi repo internet. Jika target juga harus mendapat patch Rocky yang dirilis setelah DVD ISO dibuat, paket pembaruan tersebut perlu ikut dikumpulkan; isi DVD saja belum menjamin OS terkini.

    3. Susun dan kemas menjadi .tgz

    Setelah semua bahan lengkap, susun folder repo, template, dan panduan. Buat daftar checksum untuk memastikan berkas tidak berubah saat dipindahkan. Seluruh folder kemudian dikompresi menjadi satu file, misalnya cloudstack-appliance-offline-4.23-rocky9-x86_64.tgz, disertai checksum untuk arsipnya.

    File .tgz ini adalah bundel instalasi, bukan VM atau ISO yang langsung bisa di-boot. Penerima tetap perlu menyiapkan Rocky Linux pada mesin tujuan, mengekstrak arsip, lalu mengikuti langkah instalasi.

    4. Pasang pada satu node tanpa internet

    Di mesin target, pasang Rocky Linux dengan versi yang sesuai dan putus akses WAN. Setelah .tgz diekstrak, gunakan repo lokalnya untuk memasang Management Server dan KVM agent pada mesin yang sama. Lanjutkan dengan database, jaringan, DNS, waktu, dan zona CloudStack.

    Bagian storage perlu dibedakan dengan jelas:

    • Primary storage lokal di host KVM menyimpan disk SSVM, CPVM, Virtual Router, dan guest VM.
    • NFS secondary storage pada mesin yang sama menyimpan template dan ISO. NFS ini bukan tempat disk System VM.

    Template System VM yang tersimpan offline akan dipakai untuk membuat System VM, tetapi keberadaan template saja belum membuktikan lokasi disk VM-nya.

    5. Uji sebelum disebut siap pakai

    Terakhir, pasang ulang dari .tgz pada Rocky fresh install dengan tidak terkoneksi internet. Pastikan paket terpasang, zona aktif, System VM berjalan, dan satu guest VM bisa dibuat. Periksa volume SSVM, CPVM, serta Virtual Router di CloudStack dan cocokkan path disk sebenarnya pada host KVM. Ketiganya harus berada di filesystem lokal, bukan pada NFS secondary.

    Jika seluruh langkah itu berhasil, barulah bundel .tgz dapat dinyatakan siap digunakan untuk skenario offline yang diuji.

  • Membuat Filesystem /opt dengan LVM Thin di Ubuntu

    Membuat Filesystem /opt dengan LVM Thin di Ubuntu

    Hari ini saya sedang oprek tentang lvm thin dan menempatkan /opt pada disk terpisah sebelum instalasi Carbonio. Untuk itu, disk tambahan 30 GB (/dev/xvdb) saya gunakan sebagai LVM thin pool, lalu saya buat thin volume bernama opt. Volume tersebut diformat dengan ext4 dan di-mount ke /opt. Jadi, filesystem dibuat di atas thin volume. Disk OS tetap berada di /dev/xvda.

    Sebelum mulai, pastikan /dev/xvdb benar-benar disk kosong dan /opt belum berisi aplikasi. Perintah pvcreate dapat merusak data jika dijalankan pada disk atau volume yang tidak sesuai.

    1. Periksa disk dan direktori /opt

    lsblk -f
findmnt --mountpoint /opt
ls -la /opt

    Pastikan /dev/xvdb adalah disk tambahan yang kosong dan /opt belum berisi aplikasi. Jangan lanjut jika ada data yang perlu dipertahankan.

    2. Buat volume group dan thin pool

    pvcreate /dev/xvdb
vgcreate vgthin /dev/xvdb
lvcreate --type thin-pool -L 24G -n pool vgthin

    Disk 30 GB tersebut sekarang memiliki volume group vgthin dengan thin pool 24 GB.

    3. Buat thin volume untuk /opt

    lvcreate -V 24G -T vgthin/pool -n opt

    Ukuran virtual volume opt adalah 24 GB, sama dengan ukuran pool. Jadi, contoh ini memakai LVM thin, tetapi belum mengalokasikan ukuran virtual melebihi pool.

    4. Format dan pasang ke /opt

    mkfs.ext4 /dev/vgthin/opt
mkdir -p /opt
mount /dev/vgthin/opt /opt
df -hT /opt

    Hasil:

    Filesystem             Type  Size  Mounted on
/dev/mapper/vgthin-opt ext4   24G  /opt

    5. Buat mount /opt tetap aktif setelah reboot

    Cek UUID volume opt:

    blkid /dev/vgthin/opt

    Dari hasil percobaan, UUID-nya adalah 634be5f6-b864-495a-b688-db33e14d8933. Buka /etc/fstab:

    nano /etc/fstab

    Tambahkan baris berikut di bagian bawah:

    UUID=634be5f6-b864-495a-b688-db33e14d8933  /opt  ext4  defaults  0  2

    Simpan dan periksa konfigurasi dan reload systemd:

    findmnt --verify
systemctl daemon-reload

    Jika tidak ada error, reboot server. Setelah login kembali, pastikan /opt terpasang:

    findmnt --mountpoint /opt
df -hT /opt

    Pastikan sumber mount mengarah ke vgthin-opt sebelum melanjutkan instalasi.

  • Mengatur Storage Overprovisioning di Apache CloudStack

    Mengatur Storage Overprovisioning di Apache CloudStack

    Sebelumnya saya pernah mencoba overprovisioning vCPU dan memori pada Apache CloudStack. Kali ini saya mencoba pengaturan serupa namun untuk storage, dengan mengubah storage.overprovisioning.factor pada halaman setting di Primary Storage.

    Apa itu storage overprovisioning?

    Saat membuat VM, kita bisa menentukan virtual disk sebesar 50 GB, sementara data yang benar-benar ditulis ke disk tersebut baru 5 GB. Storage overprovisioning memanfaatkan selisih antara ukuran disk yang dialokasikan dan ruang fisik yang terpakai.

    Pada storage yang mendukung fitur ini, CloudStack memakai faktor overprovisioning untuk menghitung kapasitas alokasi. Misalnya, pool fisik 100 GB dengan faktor 10 dapat dihitung memiliki kapasitas alokasi sekitar 1.000 GB. Disk fisiknya tetap 100 GB. docs.cloudstack.apache.org

    Yang dilihatContoh dengan faktor 10
    Kapasitas fisik100 GB
    Kapasitas dalam perhitungan alokasiSekitar 1.000 GB

    Cara mengubah melalui GUI

    Pada percobaan ini, saya membuka pool Filesystem / KVM / Host:

    1. Login sebagai administrator CloudStack.
    2. Buka Infrastructure → Primary Storage, lalu pilih pool.
    3. Masuk ke tab Settings dan cari overprovision.
    4. Ubah Storage overprovisioning factor menjadi 10 (sesuaikan dengan kebutuhan).
    5. Klik centang hijau, lalu refresh untuk memastikan nilainya tersimpan.

    Dampak dan Perubahan

    Jika jenis storage mendukung, perubahan ini menaikkan batas kapasitas yang dipakai CloudStack untuk menghitung alokasi virtual disk. Ukuran disk VM yang sudah ada tidak otomatis bertambah. Kapasitas fisik host juga tidak berubah.

    Untuk mengeceknya, bandingkan angka Allocated dan Used pada Primary Storage.

    Sebelum

    Sesudah

    Catatan: dokumentasi CloudStack 4.23 mencantumkan storage overprovisioning KVM untuk NFS saja, sedangkan pool pada untuk local Filesystem perlu dibandingkan sebelum dan sesudah perubahan, lalu diuji dengan deployment VM. docs.cloudstack.apache.org

    Dokumentasi: CloudStack Storage Overview · CloudStack Installation Configuration

  • Cara Membuat Repository Lokal Sederhana di Rocky Linux

    Cara Membuat Repository Lokal Sederhana di Rocky Linux

    Saya sedang menyiapkan skenario lab CloudStack lokal tanpa internet. Langkah awalnya adalah membuat Rocky Linux bisa memasang paket dari penyimpanan lokal. Contoh paling sederhana adalah menggunakan DVD ISO Rocky Linux 9 sebagai sumber paket. Pastikan ISO sesuai dengan versi dan arsitektur server. Gunakan DVD ISO, bukan minimal atau boot ISO.

    Di contoh ini, file ISO sudah tersedia di /root/Rocky-9-dvd.iso. Sesuaikan nama file dengan ISO yang dimiliki, dan sediakan ruang disk yang cukup untuk menyalin isinya. Langkah ini membuat repo untuk server tersebut, belum membagikannya ke server lain.

    1. Salin isi repository dari ISO

    # sudo mkdir -p /mnt/rocky-dvd /srv/repo/rocky
# sudo mount -o loop /root/Rocky-9-dvd.iso /mnt/rocky-dvd
# ls /mnt/rocky-dvd/{BaseOS,AppStream}/repodata/repomd.xml
# sudo cp -a /mnt/rocky-dvd/BaseOS /mnt/rocky-dvd/AppStream /srv/repo/rocky/
# sudo umount /mnt/rocky-dvd

    Folder BaseOS dan AppStream berisi paket serta metadata yang sudah bisa dibaca DNF. Karena itu, untuk contoh ini saya tidak perlu menjalankan createrepo lagi.

    2. Daftarkan repository lokal

    Pastikan kunci GPG Rocky Linux tersedia dengan ls /etc/pki/rpm-gpg/RPM-GPG-KEY-Rocky-9, lalu buat file /etc/yum.repos.d/rocky-local.repo:

    [local-baseos]
name=Rocky Linux 9 - BaseOS Lokal
baseurl=file:///srv/repo/rocky/BaseOS
enabled=1
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-Rocky-9

[local-appstream]
name=Rocky Linux 9 - AppStream Lokal
baseurl=file:///srv/repo/rocky/AppStream
enabled=1
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-Rocky-9

    DNF membaca konfigurasi repository dari file .repo di /etc/yum.repos.d/. Red Hat Documentation

    3. Uji tanpa repository internet

    # dnf --disablerepo='*' --enablerepo=local-baseos --enablerepo=local-appstream --refresh makecache
# dnf --disablerepo='*' --enablerepo=local-baseos --enablerepo=local-appstream install vim-enhanced

    Jika metadata terbaca dan vim-enhanced terpasang, repo lokal Rocky Linux sudah berfungsi. Bila paket itu sudah terpasang sebelumnya, gunakan paket lain yang tersedia di ISO untuk menguji instalasi. Opsi --disablerepo='*' membuat kedua perintah hanya memakai repo lokal; repo internet bawaan tetap aktif untuk perintah DNF biasa sampai dinonaktifkan.

    Kalo Ada Update?

    Repository dari DVD ISO tidak diperbarui otomatis. Paket yang tersedia mengikuti isi ISO saat dibuat.

    Jika ada DVD ISO Rocky Linux 9 yang lebih baru, salin kembali folder BaseOS dan AppStream ke direktori baru, misalnya /srv/repo/rocky-baru. Setelah itu, ubah kedua baseurl di rocky-local.repo agar mengarah ke direktori baru. Jangan mencampur isi repo lama dan baru supaya paket tetap sesuai dengan metadatanya.

    Jalankan pembaruan hanya dari repo lokal:

    # dnf --disablerepo='*' --enablerepo=local-baseos \
  --enablerepo=local-appstream --refresh upgrade

    Jika membutuhkan patch yang terbit sebelum ada ISO baru, sinkronkan paket beserta metadata di mesin yang memiliki internet menggunakan dnf reposync --download-metadata, lalu pindahkan hasilnya ke server offline.

    Referensi

  • Error “No destination found” CloudStack: Cek CPU, Offering, dan Storage

    Error “No destination found” CloudStack: Cek CPU, Offering, dan Storage

    Saat menguji Apache CloudStack dengan KVM, saya menaikkan overprovisioning CPU dan RAM untuk menguji agar lab dapat menjalankan lebih banyak instance. Namun, beberapa kali pembuatan instance tetap gagal dengan error

    No destination found for a deployment for VM instance.

    Error ini belum menunjukkan penyebab pastinya. Dalam pengujian saya, ada tiga pengaturan yang saya periksa setelah konsultasi denga AI:

    Log management-server.logTindakan
    No clusters found having a host with enough capacityPeriksa faktor CPU dan RAM pada cluster.
    disk profile does not use local storage atau No storage pools available for [shared]Pilih offering untuk ROOT disk yang menggunakan Local Storage.
    allocated percentage ... crossed ... 0.85Periksa batas alokasi storage pada zone.

    1. Periksa faktor CPU dan RAM

    • Buka Infrastructure → Clusters → pilih cluster → Settings,
    • Cari pengaturan overprovisioning.
    • Ubah cpu.overprovisioning.factor dan mem.overprovisioning.factor
    • Dalam lab ini, saya memakai:
    CPU Overprovisioning Factor    = 10
Memory Overprovisioning Factor = 10

    Faktor 10 hanya untuk pengujian, bukan rekomendasi production. Overprovisioning memperbesar kapasitas yang dihitung CloudStack, bukan CPU atau RAM fisik. Pada KVM, faktor memory juga dapat memengaruhi memori minimum saat guest mulai berjalan. Periksa kapasitas host dan memori yang tersedia di guest setelah perubahan.

    2. Sesuaikan Storage Type untuk ROOT disk

    Pada kasus lain, CPU dan RAM sudah lolos, tetapi log menampilkan 

    No storage pools available for [shared] volume allocation.

    Ternyata offering yang dipakai meminta Shared Storage, sedangkan lab menggunakan Local Storage.

    • Buka Service Offerings → Compute Offerings.
    • Periksa pengaturan ROOT disk atau Disk Offering yang ditautkan, lalu pilih Storage Type: Local.

    Jika offering yang digunakan tidak dapat disesuaikan, buat offering baru dengan tipe Local dan pilih saat membuat instance.

    3. Periksa batas alokasi storage

    CPU, RAM, dan tipe storage sudah sesuai, tetapi ROOT disk 20 GB masih ditolak. Log menunjukkan alokasi sebelumnya 65.77 GB; jika ditambah 20 GB, totalnya 85.77 GB dari kapasitas hasil overprovisioning 95.85 GB:

    85.77 / 95.85 ≈ 89.48%
Batas allocated storage = 85% (0.85)

    Untuk pengujian:

    • Buka Infrastructure → Zones → pilih zone → Settings,
    • Cari bagian pool.storage.allocated.capacity.disablethreshold.
    • Jika ruang fisik masih cukup, sesuaikan batasnya, misalnya dari 0.85 menjadi 0.95.

    Menaikkan batas ini tidak menambah kapasitas disk fisik. Tetap pantau ruang kosong filesystem host, terutama ketika storage juga di-overprovision. Jika diperlukan, faktor overprovisioning storage dapat ditinjau secara terpisah.

    Saat error muncul lagi

    Jangan langsung menaikkan faktor CPU dan RAM. Cari petunjuk sebelum baris No destination found pada log management server:

    tail -f /var/log/cloudstack/management/management-server.log

    Periksa menggunakan UUID Instance:

    grep -i "<UUID-INSTANCE>" /var/log/cloudstack/management/management-server.log

    Intinya: pastikan compute capacity cukup, ROOT disk meminta tipe storage yang tersedia, dan alokasinya belum melewati batas pool.

    Referensi

  • Memahami LVM Thin Provisioning

    Memahami LVM Thin Provisioning

    Hari ini saya ditugaskan untuk mencoba LVM Thin. Sembari saya oprek dan testing, saya mencari tahu dulu cara kerjanya secara sederhana, terutama perbedaan antara ukuran volume yang terlihat dan ruang disk yang benar-benar dipakai.

    Dasar LVM

    LVM adalah cara Linux mengelola ruang penyimpanan. Ada tiga istilah yang perlu dikenali:

    IstilahArtinya
    PV (physical volume)Disk atau partisi yang disiapkan untuk LVM.
    VG (volume group)Tempat mengumpulkan ruang dari PV.
    LV (logical volume)Volume yang dibuat dari ruang VG.

    Urutannya adalah PV → VG → LV. Pada LVM Thin, ada satu bagian tambahan bernama thin pool. Pool ini dibuat dari ruang VG dan menjadi tempat thin volume mengambil ruang untuk menyimpan data.

    Apa bedanya dengan LV biasa?

    LV biasaLVM Thin
    Ruang sebesar ukuran LV disediakan saat LV dibuat.Thin volume memiliki ukuran yang terlihat oleh sistem, tetapi ruang di pool dipakai saat data ditulis.
    Ruang untuk LV diambil langsung dari VG.Ruang untuk thin volume diambil dari thin pool.

    Ukuran yang terlihat pada thin volume disebut ukuran virtual. Jadi, ketika sebuah thin volume terlihat memiliki kapasitas tertentu, belum tentu sebanyak itu ruang fisik di thin pool sudah terpakai.

    Hal yang sempat membuat saya bingung adalah thin pool dan thin volume memakai ruang pada tahap yang berbeda. Thin pool mengambil ruang dari VG saat dibuat. Setelah itu, thin volume memakai ruang di dalam pool saat data ditulis. Karena itulah ruang kosong pada VG tidak sama dengan ruang kosong di thin pool.

    Kesimpulan

    Sejauh yang saya pahami, LVM Thin memungkinkan volume dibuat tanpa langsung memakai seluruh ukuran virtualnya sebagai ruang penyimpanan data. Ruang fisik tetap memiliki batas, jadi ukuran volume yang terlihat perlu dibedakan dari ruang yang tersedia di thin pool. Ini dasar yang ingin saya pahami sebelum melanjutkan praktik.