Rafi Harlianto

Informatics Engineering

Category: IT

  • 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.

  • 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

  • Mengatur CPU dan RAM Overprovisioning pada Apache CloudStack

    Mengatur CPU dan RAM Overprovisioning pada Apache CloudStack

    Saat melakukan uji coba Apache CloudStack, atasan saya sedang menguji proses import VM dari VMware ke lingkungan CloudStack. Setelah beberapa VM dijalankan, saya diminta menguji overprovisioning pada CloudStack agar kapasitas CPU dan RAM host dapat dialokasikan kepada lebih banyak VM tanpa langsung menambah resource fisik.

    Overprovisioning pada CloudStack hanya memperbesar kapasitas yang digunakan oleh scheduler dalam menentukan apakah sebuah VM masih dapat ditempatkan pada host. Jika seluruh VM menggunakan resource secara bersamaan, tetap dapat terjadi CPU contention atau kekurangan RAM.

    Cara Kerja Overprovisioning

    CloudStack menyediakan dua parameter pada level cluster:

    • cpu.overprovisioning.factor
    • mem.overprovisioning.factor

    Nilai 1.0 berarti tidak ada overprovisioning. Contohnya, jika host memiliki 4 vCPU dan RAM 8 GB:

    ParameterFactorKapasitas dalam perhitungan CloudStack
    CPU10.04 x 10 = 40 vCPU
    RAM10.08 x 10 = 80 GB

    Konfigurasi Melalui GUI

    1. Login ke CloudStack sebagai Root Administrator.
    2. Buka Infrastructure.
    3. Pilih Clusters.
    4. Klik cluster tempat host berada.
    5. Buka tab Settings.
    6. Cari kata overprovisioning.
    7. Ubah CPU overcommit factor
    8. Ubah RAM overcommit factor
    9. Simpan perubahan dan tunggu pembaruan capacity.

    Pengaturan pada cluster lebih tepat dibandingkan hanya mengubah Global Settings karena kemampuan setiap cluster dapat berbeda. Global Settings berfungsi sebagai nilai default ketika cluster baru dibuat.

    Verifikasi

    Sebelum dan sesudah perubahan, periksa kapasitas melalui menu:

    Infrastructure → System Wide Capacity

    Selanjutnya, coba deploy atau start beberapa VM menggunakan service offering yang sama. Pantau penggunaan resource pada host KVM:

    free -h
top
vmstat 1

    VM yang dibuat setelah perubahan akan memakai perhitungan baru. Untuk VM lama, lakukan stop dan start agar CloudStack menghitung ulang used dan reserved capacity.

    Catatan untuk RAM pada KVM

    RAM overprovisioning lebih berisiko dibandingkan CPU. Pada KVM, guest VM sebaiknya memiliki virtio balloon driver agar hypervisor dapat melakukan memory ballooning. Hal ini perlu diperhatikan pada VM hasil import dari VMware karena driver yang dibutuhkan belum tentu sudah tersedia di dalam guest OS.

    CloudStack juga mengatur minimum RAM VM berdasarkan nilai service offering yang dibagi dengan RAM overcommit factor. Karena itu, kapasitas RAM yang terbaca di dalam guest perlu diperiksa setelah VM dinyalakan. Jangan menerapkan RAM overprovisioning besar sebelum balloon driver dan penggunaan RAM host sudah diverifikasi.

    Kesimpulan

    CPU dan RAM overprovisioning dapat membantu menjalankan lebih banyak VM pada resource host yang sama. Penggunaan CPU, RAM, dan stabilitas VM harus tetap dipantau sebelum factor dinaikkan kembali.

    Referensi

  • Memahami CloudStack Networking

    Memahami CloudStack Networking

    Saat ini saya sedang mencoba Apache CloudStack di lingkungan lab. Networking dasar seperti IP address, subnet, dan gateway secara umum sudah bisa saya pahami. Bagian yang masih saya pelajari adalah bagaimana CloudStack memakai konsep tersebut untuk mengatur jaringan VM.

    Setelah membaca artikel ShapeBlue – A Beginner’s Guide to CloudStack Networking dan sedikit dokumentasi cloudstack, baru saya mulai memahami.

    Empat Jenis Trafik CloudStack

    Hal pertama yang perlu dipahami adalah CloudStack membagi trafik jaringan berdasarkan fungsinya.

    Jenis trafikFungsi
    ManagementKomunikasi Management Server, host, dan System VM
    GuestTrafik antar-VM dan trafik VM menuju gateway
    PublicMenghubungkan guest network dengan jaringan luar
    StorageTransfer template, ISO, dan snapshot

    Keempat trafik tersebut tidak selalu membutuhkan empat NIC fisik. Pada lab, beberapa trafik dapat digabung dalam satu interface. Pada production, pemisahan NIC atau VLAN lebih disarankan.

    Management Network

    Management network digunakan untuk komunikasi Management Server, host hypervisor, Secondary Storage VM, Console Proxy VM, dan System VM lainnya.

    Saat membuat pod, kita menyediakan Reserved System IP khusus untuk System VM. Range ini berbeda dari IP Management Server, IP host, Public IP, dan IP user VM. Sederhananya, management network adalah jalur kontrol internal CloudStack.

    Guest Network

    Guest network adalah jaringan yang digunakan oleh VM. Trafik antar-VM dan trafik VM menuju gateway akan melewati jaringan ini.

    Pada Advanced Networking, guest network dapat berupa:

    • Isolated Network, yaitu jaringan yang dipisahkan untuk Account tertentu.
    • Shared Network, yaitu jaringan yang dapat digunakan bersama sesuai scope yang ditentukan.
    • VPC, yaitu beberapa network tier yang dihubungkan melalui VPC Virtual Router.

    Pada isolated network, CloudStack memberikan VLAN tersendiri. VM memperoleh private IP dan menggunakan Virtual Router sebagai default gateway. Karena terpisah secara Layer 2, isolated network yang berbeda secara konsep dapat memakai CIDR private yang sama tanpa saling terhubung.

    Public Network

    Istilah Public Network di CloudStack tidak selalu berarti IP publik Internet. Public network adalah jaringan yang berada di sisi luar Virtual Router.

    Dalam private cloud, Public IP dapat menggunakan IP private seperti 192.168.x.x. IP tersebut tetap disebut Public IP oleh CloudStack karena posisinya berada di luar guest network.

    Public IP digunakan untuk Source NAT, Static NAT, port forwarding, load balancing, dan VPN.

    Pada isolated network, VM tetap menggunakan private IP. Public IP dipasang pada sisi luar Virtual Router, lalu diterjemahkan menuju private IP VM.

    Alur nya:

    VM
IP: 10.1.1.100/24
Default gateway: 10.1.1.1
        ↓
Virtual Router
Guest interface: 10.1.1.1
        ↓
Source NAT
10.1.1.100 → 192.168.1.10
        ↓
Public interface Virtual Router
IP: 192.168.1.10/24
        ↓
Public gateway
192.168.1.1
        ↓
Internet

    Jadi, pada isolated network, Public IP tidak langsung menjadi IP pada NIC VM.

    Storage Network

    Storage network menangani trafik Secondary Storage seperti download template dan ISO, penyalinan template ke Primary Storage, serta pemindahan snapshot. Jika tidak dibuat terpisah, trafik ini dapat melewati management network. Pada lingkungan dengan transfer data besar, pemisahan storage network lebih disarankan.

    Basic dan Advanced Networking

    CloudStack menyediakan dua model networking utama:

    Basic NetworkingAdvanced Networking
    Umumnya satu guest networkDapat memiliki banyak network
    Isolasi memakai Security GroupIsolasi menggunakan VLAN dan Layer 3
    Konfigurasi lebih sederhanaMendukung isolated network, NAT, VPN, dan VPC

    Untuk private cloud dengan beberapa Account dan network terpisah, Advanced Networking lebih relevan. Pilihan model ditentukan saat membuat zone dan tidak dapat diganti setelah zone selesai dikonfigurasi.

    Virtual Router

    Virtual Router adalah System VM yang menjadi komponen utama pada isolated network. CloudStack membuat dan mengelolanya secara otomatis ketika network mulai digunakan.

    Virtual Router dapat menyediakan gateway, DHCP, DNS, NAT, firewall, port forwarding, load balancing, dan VPN. Layanan yang tersedia bergantung pada Network Offering, sehingga dua isolated network dapat memiliki kemampuan berbeda.

    Pada mode NATTED, Virtual Router melakukan NAT antara guest network dan Public network. CloudStack juga mendukung mode ROUTED, tetapi cara akses ke jaringan luar berbeda karena tidak memakai layanan NAT seperti mode NATTED.

    Hubungan dengan VLAN dan Switch

    CloudStack dapat membuat interface virtual dan mengalokasikan VLAN, tetapi jaringan fisik tetap harus disiapkan sebelumnya.

    Guest VLAN dan Public VLAN harus diizinkan pada bridge host, switch port, trunk antar-switch, serta router yang menjadi gateway.

    Jika VLAN sudah dimasukkan ke CloudStack tetapi belum diizinkan pada switch, VM mungkin berhasil dibuat tetapi tidak memperoleh DHCP, tidak dapat mencapai gateway, atau tidak dapat mengakses jaringan luar.

    Kesimpulan

    Setelah dipisahkan berdasarkan fungsi, networking CloudStack menjadi sedikit lebih mudah dipahami:

    • Management network digunakan untuk mengelola infrastruktur.
    • Guest network digunakan oleh VM.
    • Public network menghubungkan Virtual Router dengan jaringan luar.
    • Storage network membawa trafik template, ISO, dan snapshot.

    Pada Advanced Networking, Virtual Router menghubungkan private guest network dengan Public network, sedangkan VLAN memisahkan network pada Layer 2. CloudStack tidak menggantikan networking dasar, tetapi mengotomatisasi penggunaan subnet, gateway, VLAN, routing, NAT, dan firewall untuk VM serta Account.

    Referensi