Saat testing CloudStack 4.23 di Rocky Linux 9.8, saya mengalami kendala ketika menambahkan host KVM melalui menu Add Host. Prosesnya gagal dengan pesan berikut:
Unable to add the host:
Cannot find the server resources at http://192.168.14.9
Salah satu konfigurasi yang perlu diperiksa adalah alamat Management Server pada file agent.properties. Untuk penyesuaian ini, alamat tersebut diarahkan menggunakan IP Management Server.
Parameter host berisi alamat Management Server yang dituju oleh CloudStack Agent. Jadi, nilainya harus mengarah ke Management Server yang dapat dijangkau dari host KVM.
Jika sebelumnya menggunakan hostname, pastikan hostname tersebut mengarah ke IP yang benar. Penggunaan IP langsung dapat menghindari ketergantungan pada resolusi hostname untuk alamat ini.
2. Ubah menjadi IP Management Server
Backup konfigurasi terlebih dahulu:
cp -a /etc/cloudstack/agent/agent.properties \
/etc/cloudstack/agent/agent.properties.bak
Kemudian buka file:
vi /etc/cloudstack/agent/agent.properties
Cari parameter host, lalu sesuaikan:
host=192.168.14.9
Contoh tersebut berlaku jika Management Server berada di 192.168.14.9. Jika Management Server dan KVM menggunakan server berbeda, isi dengan IP Management Server, bukan IP host KVM. Tulis IP tanpa awalan http://.
3. Restart CloudStack Agent
Setelah disimpan, restart layanan:
systemctl restart cloudstack-agent
systemctl status cloudstack-agent
Periksa log agent:
tail -n 100 /var/log/cloudstack/agent/agent.log
Periksa kembali apakah masih ada error koneksi pada log.
4. Periksa kembali melalui dashboard
Kembali ke halaman Hosts dan refresh. Jika host sudah terdaftar, periksa apakah statusnya Up. Jika belum, coba kembali Add Host.
Jika penyesuaian IP belum menyelesaikan kendala, lanjutkan pemeriksaan log agent dan Management Server untuk mencari penyebabnya.
Saya sedang testing Apache CloudStack untuk kebutuhan lab tanpa akses internet. Project ini merupakan arahan dari atasan saya sebagai persiapan rencana migrasi VM dari VMware ke KVM yang dikelola melalui CloudStack. Tujuannya agar disk VM dari VMware dapat dikonversi dan digunakan pada KVM.
Awalnya, saya mengumpulkan paket dan kebutuhan instalasi ke dalam satu bundle, lalu menyiapkan alur deployment CloudStack menggunakan repository lokal.
Tujuannya sederhana: bahan-bahan disiapkan terlebih dahulu di server yang memiliki internet, kemudian dipindahkan ke server target. Dengan begitu, instalasi tidak perlu mengambil paket dari repository online.
Memisahkan Persiapan dan Deployment
Saya membagi pekerjaan ini menjadi dua bagian:
Server staging dengan internet, untuk mengunduh paket, dependensi, ISO, dan template.
Server target tanpa internet, untuk menggunakan bundle dan menjalankan setup CloudStack melalui jaringan lokal.
Staging menggunakan Rocky Linux 9.7, sedangkan target bundle menggunakan Rocky Linux 9.8. Karena berbeda, sumber paket untuk bundle saya arahkan ke versi OS target agar sesuai dengan lingkungan deployment.
Untuk lab ini, Management Server, database, dan host KVM ditempatkan pada satu server agar alurnya lebih sederhana.
1. Menyiapkan Isi Bundle
Persiapan dimulai dari mengumpulkan kebutuhan CloudStack 4.23 beserta komponen pendukungnya. Isi bundle dibagi berdasarkan fungsi:
ISO Rocky Linux 9.8 Minimal untuk instalasi OS target.
Repo CloudStack berisi paket Management Server, agent, database, KVM, dan dependensinya.
Template System VM beserta metadata yang sesuai dengan paket CloudStack.
Repo migrasi VMware untuk kebutuhan konversi VM.
Folder berkas vendor, termasuk kebutuhan VDDK untuk metode migrasi yang akan digunakan.
README dan checksum sebagai petunjuk penggunaan serta pemeriksaan file.
Paket migrasi dipisahkan agar kebutuhan instalasi dasar CloudStack lebih mudah dibaca dan digunakan.
2. Melengkapi Dependensi dan Membuat Repo Lokal
Pada tahap awal testing, saya menemui paket pendukung yang belum tersedia dan ketidakcocokan versi paket. Dari sini terlihat bahwa menyalin RPM CloudStack saja belum cukup untuk instalasi offline.
Saya kemudian menyesuaikan pengumpulan paket agar dependensinya ikut tersedia, termasuk paket yang sudah terpasang pada staging tetapi belum tentu ada di target.
Setelah paket terkumpul, saya membuat metadata repository. Folder tersebut kemudian dapat digunakan oleh DNF sebagai repo lokal, sehingga pemasangan paket tetap mengikuti mekanisme dependency seperti instalasi biasa.
3. Menyiapkan Template System VM
Selain paket RPM, saya juga menyiapkan template System VM. Template ini merupakan image untuk VM pendukung CloudStack dan disimpan terpisah dari repo paket.
Pemilihan template mengikuti metadata dari RPM Management Server yang digunakan. Tujuannya agar paket CloudStack dan template dalam bundle sesuai, serta setup tidak perlu mengunduh template melalui internet.
4. Mengemas dan Memindahkan Bundle
Seluruh bahan disusun dalam satu direktori, dilengkapi README dan checksum, lalu dikemas menjadi arsip .tgz.
Bundle ini menjadi bahan deployment yang dapat dipindahkan ke server target. Di target, arsip diekstrak dan repository diarahkan ke folder lokal menggunakan file://. Saat memasang paket, hanya repo dari bundle yang digunakan.
5. Melanjutkan Setup CloudStack
Alur deployment kemudian dilanjutkan dengan konfigurasi hostname, jaringan bridge, database, KVM, dan Management Server. Setelah itu, konfigurasi zone, host, serta storage dilakukan melalui antarmuka CloudStack.
Untuk kebutuhan lab, saya memilih local primary storage dan disk System VM di storage lokal host KVM. Secondary storage tetap disiapkan untuk menyimpan template, ISO, dan snapshot.
Offline di sini berarti tidak bergantung pada internet. Komunikasi antar-komponen dan akses administrasi tetap menggunakan jaringan lokal.
Pengujian
Fokus pengujian ini adalah memastikan bundle cukup untuk menjalankan setup tanpa mengambil bahan tambahan dari internet. Pemeriksaannya mencakup instalasi paket, akses Management Server, pendaftaran host, kesiapan storage, dan System VM.
Kebutuhan migrasi VMware ikut disiapkan dalam bundle, tetapi pengujian migrasinya menjadi tahap terpisah. Begitu juga deploy instance pengguna, yang membutuhkan ISO atau template OS guest tersendiri.
Dari proses ini, bagian paling penting adalah kelengkapan bahan dan kesesuaian versi. Repo lokal menyediakan paket, sedangkan bundle menyatukan kebutuhan deployment agar alurnya lebih mudah diulang.
Saat testing integrasi Ceph sebagai primary storage CloudStack pada Rocky Linux 9, saya menemui kendala saat menambahkan storage dan membuat instance. Dua komponen masih menggunakan opsi auth_supported, yang ditolak library klien Ceph pada lab saya.
Perbaikannya adalah mengganti opsi tersebut menjadi auth_client_required. Untuk memudahkan penerapan ulang, saya menyiapkan dua script di GitHub.
Fungsi masing-masing script
Bagian A — fix-libvirt-rbd.sh: memperbaiki driver storage RBD libvirt untuk error failed to set RADOS option: auth_supported saat menambahkan primary storage.
Bagian B — fix-cloudstack-agent-rbd.sh: memperbaiki plugin KVM agent untuk error invalid conf option auth_supported saat konversi template atau disk instance.
Keduanya melakukan pengecekan sederhana, menyediakan backup dan rollback, serta melewati pemasangan jika komponen aktif sudah menggunakan opsi baru.
Persiapan
Ceph, pool RBD, konfigurasi klien, dan keyring harus sudah tersedia. Pastikan akses dari host KVM berhasil:
rbd --id cloudstack -p cloudstack-pool ls
Default script memakai Rocky 9 x86_64, libvirt 11.10.0-12.7.el9_8, dan CloudStack agent 4.23.0.0. Sesuaikan versi, URL, path, dan nama layanan melalui variabel di atas script. Patch tidak membutuhkan secret Ceph.
Build sebaiknya dilakukan pada mesin Rocky dengan rilis, arsitektur, dan repository klien Ceph yang sesuai host KVM:
sudo bash fix-libvirt-rbd.sh build
Hasilnya ada di /root/libvirt-rbd-backport/fixed.rpm. Jika mesin build terpisah, salin RPM ke path yang sama pada host KVM dan unduh script A di host tersebut. Kemudian pasang:
sudo bash fix-libvirt-rbd.sh install
Bagian A hanya memasang subpaket driver RBD hasil build, kemudian me-restart libvirt dan menghentikan sementara agent yang aktif.
Jalankan Bagian B
Pada host KVM:
sudo bash fix-cloudstack-agent-rbd.sh apply
Script compile ulang satu class Java, memeriksa API dan bytecode, lalu mengganti plugin dan menghentikan sementara agent yang aktif. Jalankan pemasangan ketika tidak ada deployment atau migrasi berlangsung.
Cek hasil dan rollback
Tunggu host dan primary storage berstatus Up, lalu coba deployment. Pastikan instance Running dan ROOT volume berada di storage Ceph. Patch ini menangani error kompatibilitas opsi RBD; kapasitas host, template, dan offering tetap harus sesuai.
Jika perlu mengembalikan perubahan, jalankan pada host KVM dengan direktori kerja yang sama:
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:
Komponen
IP
Versi
Management dan KVM
192.168.14.8
CloudStack 4.23, Rocky Linux 9.8, libvirt 11.10.0
Proxmox Ceph
192.168.14.4
Squid 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:
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.
Setelah perubahan diterapkan, melakukan restart libvirt dan CloudStack Agent.
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.
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:
Hubungkan CloudStack ke vCenter untuk menampilkan daftar VM.
Pilih VM, kemudian tentukan cluster KVM, account, resource, dan jaringan tujuan.
Ekspor file VM ke storage sementara.
Jalankan konversi menggunakan virt-v2v.
Impor hasil konversi menjadi instance CloudStack.
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.
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.
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 dilihat
Contoh dengan faktor 10
Kapasitas fisik
100 GB
Kapasitas dalam perhitungan alokasi
Sekitar 1.000 GB
Cara mengubah melalui GUI
Pada percobaan ini, saya membuka pool Filesystem / KVM / Host:
Login sebagai administrator CloudStack.
Buka Infrastructure → Primary Storage, lalu pilih pool.
Masuk ke tab Settings dan cari overprovision.
Ubah Storage overprovisioning factor menjadi 10 (sesuaikan dengan kebutuhan).
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
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.log
Tindakan
No clusters found having a host with enough capacity
Periksa 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.
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:
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:
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:
Parameter
Factor
Kapasitas dalam perhitungan CloudStack
CPU
10.0
4 x 10 = 40 vCPU
RAM
10.0
8 x 10 = 80 GB
Konfigurasi Melalui GUI
Login ke CloudStack sebagai Root Administrator.
Buka Infrastructure.
Pilih Clusters.
Klik cluster tempat host berada.
Buka tab Settings.
Cari kata overprovisioning.
Ubah CPU overcommit factor
Ubah RAM overcommit factor
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.
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.
Hal pertama yang perlu dipahami adalah CloudStack membagi trafik jaringan berdasarkan fungsinya.
Jenis trafik
Fungsi
Management
Komunikasi Management Server, host, dan System VM
Guest
Trafik antar-VM dan trafik VM menuju gateway
Public
Menghubungkan guest network dengan jaringan luar
Storage
Transfer 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 Networking
Advanced Networking
Umumnya satu guest network
Dapat memiliki banyak network
Isolasi memakai Security Group
Isolasi menggunakan VLAN dan Layer 3
Konfigurasi lebih sederhana
Mendukung 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.
