Rafi Harlianto

Informatics Engineering

Category: IT

  • Mengenal OneSwap: Tools Migrasi VMWare OpenNebula

    Mengenal OneSwap: Tools Migrasi VMWare OpenNebula

    Saya sedang menyiapkan lab OpenNebula untuk testing migrasi VM dari VMware ke KVM. Salah satu tool yang saya pelajari untuk kebutuhan ini adalah OneSwap.

    OneSwap merupakan tool berbasis command line dari OpenNebula yang membantu konversi VM dari VMware vCenter ke OpenNebula/KVM. Selain mengambil VM melalui vCenter, tool ini juga mendukung impor file OVA yang sebelumnya diekspor dari lingkungan VMware.

    Dalam prosesnya, OneSwap menggunakan tool seperti virt-v2v atau qemu-img untuk konversi. OneSwap juga membantu membuat image dan template VM di OpenNebula, sehingga beberapa pekerjaan yang biasanya dilakukan manual dapat diotomatisasi.

    Secara sederhana, alur penggunaannya:

    1. Siapkan lingkungan tujuan, meliputi OpenNebula, host KVM, datastore, dan jaringan.
    2. Siapkan VM sumber, melalui akses vCenter atau file OVA hasil ekspor.
    3. Jalankan konversi menggunakan OneSwap, lalu impor hasilnya ke datastore dan buat template VM di OpenNebula.
    4. Jalankan dan periksa VM, mulai dari boot sistem operasi, disk, jaringan, hingga layanan aplikasinya.

    Di lab, target berikutnya adalah menggunakan Ceph dari lingkungan Proxmox sebagai datastore OpenNebula. Integrasi storage ini perlu disiapkan terlebih dahulu sebelum mencoba migrasi VM.

    OneSwap dapat menyederhanakan proses perpindahan VM. Namun, hasil migrasi tetap perlu diperiksa. VM yang sudah berhasil dikonversi belum tentu langsung memiliki konfigurasi jaringan dan layanan yang sesuai di lingkungan tujuan.

    Referensi:

  • Instalasi OpenNebula 7.4 Menggunakan miniONE

    Hari ini saya mencoba menginstal OpenNebula di server lab. Untuk tahap awal, saya menggunakan miniONE agar proses instalasinya lebih sederhana dan bisa langsung mengenal tampilan serta komponen OpenNebula.

    miniONE membantu menyiapkan lingkungan evaluasi OpenNebula melalui satu script. Pada pengujian ini, front-end dan host KVM dipasang pada server yang sama.

    1. Download Script miniONE

    Gunakan akun root pada server script miniONE versi 7.4.0 diunduh dari repository resmi OpenNebula:

    wget https://github.com/OpenNebula/minione/releases/download/v7.4.0/minione

    Setelah selesai, saya menjalankan script melalui Bash sekaligus menentukan versi OpenNebula yang akan dipasang:

    bash minione

    2. Pemeriksaan Instalasi dari miniONE

    Sebelum instalasi dimulai, miniONE memeriksa kondisi server dan menampilkan komponen yang akan dipasang.

    Pada pengujian ini, rencana instalasinya meliputi:

    • OpenNebula front-end versi 7.4.
    • MariaDB sebagai backend database.
    • Node virtualisasi KVM.
    • Bridge minionebr dengan IP 172.16.100.1/24.
    • NAT melalui interface ens18.
    • Appliance Alpine Linux 3.20 dari Marketplace.

    Installer juga menampilkan bahwa firewalld tetap aktif dan SELinux tetap enforcing.

    Setelah pemeriksaan tersebut, jawab yes:

    Do you agree? [yes/no]:
yes

    3. Proses Instalasi dan Konfigurasi

    Kemudian, miniONE menjalankan pemasangan paket dan konfigurasi secara otomatis. Prosesnya mulai dari pembuatan bridge, pengaturan NAT, konfigurasi repository, instalasi OpenNebula, dan penyiapan MariaDB.

    Bridge minionebr digunakan sebagai jaringan internal VM, sedangkan NAT melalui ens18 disiapkan sebagai jalur keluar dari jaringan tersebut.

    Installer kemudian mengatur layanan OpenNebula, akses SSH akun oneadmin, datastore lokal, host KVM, dan virtual network.

    Contoh log instalasi:

    Installing OpenNebula packages  OK
Installing OpenNebula kvm node packages  OK
Installing and starting MariaDB  OK
Starting OpenNebula services  OK
Enabling OpenNebula services  OK
Creating kvm host  OK
Ensure host is synced  OK
Creating virtual network  OK

    Di bagian akhir, miniONE mengunduh image Alpine Linux 3.20 dari Marketplace ke datastore lokal, menunggu image siap, lalu memperbarui template VM:

    Exporting [Alpine Linux 3.20] from Marketplace to local datastore  OK
Waiting until the image is ready  OK
Updating VM template  OK

    Image dan template tersebut dapat digunakan untuk pengujian.

    4. Akses Sunstone

    Setelah instalasi selesai, miniONE hasil berikut:

    ### Report
OpenNebula 7.4 was installed
Database backend: MySQL (MariaDB), database 'opennebula'
Sunstone is running on:
  http://192.168.14.21/
Use following to login:
  user: oneadmin
  password: <password-dari-installer>

    Buka alamat http://192.168.14.21/ melalui browser, kemudian login menggunakan akun oneadmin dan password yang ditampilkan installer.

    Sunstone merupakan antarmuka web untuk mengelola resource OpenNebula. Setelah login, pengecekan awal dapat dilakukan melalui GUI:

    KomponenYang diperiksa
    HostHost KVM lokal sudah terdaftar dan terpantau
    DatastoreDatastore lokal tersedia
    Virtual networkJaringan yang dibuat miniONE tersedia
    ImageAlpine Linux 3.20 sudah siap
    TemplateTemplate Alpine tersedia untuk pengujian

    Berdasarkan log terbaru, instalasi OpenNebula 7.4 telah selesai, host KVM berhasil dibuat dan disinkronkan, serta image Alpine sudah disiapkan. Tahap berikutnya adalah mencoba deployment VM melalui Sunstone untuk memastikan resource tersebut dapat digunakan.

    OpenNebula dapat menjadi alternatif migrasi dari VMware, dengan VM dijalankan pada KVM.

    Migrasi dapat dibantu menggunakan OneSwap, melalui akses vCenter atau file OVA hasil ekspor. Alurnya dimulai dari menyiapkan OpenNebula, mengonversi dan mengimpor VM, lalu memeriksa boot OS, disk, jaringan, serta layanan aplikasi.

    Instalasi miniONE ini menjadi tahap awal sebelum pengujian migrasi dilakukan.

    Dokumentasi: ;Migrating VMs with OneSwap — OpenNebula 7.4.

  • Penggunaan Proxmox dan Ceph untuk Production

    Penggunaan Proxmox dan Ceph untuk Production

    Hari ini saya melanjutkan membaca artikel dari Mr.PlanB tentang penggunaan Proxmox di lingkungan production. Artikel ini membahas pengalaman beberapa system admin yang menggunakan Proxmox untuk menjalankan ratusan hingga lebih dari 10.000 VM.

    Dari beberapa pembahasan tersebut, ada pembahasan yang menarik pada bagian penggunaan Ceph sebagai storage Proxmox, terutama mengenai risiko penggunaan Ceph dengan jumlah node yang sedikit.

    Dalam artikel tersebut, seorang system admin yang menggunakan Ceph pada cluster dengan jumlah node cukup banyak. Namun, ada juga yang merasa bahwa penggunaan Ceph dengan tiga node masih berisiko ketika salah satu node mengalami kegagalan. Untuk kebutuhan production yang kritis, salah satu administrator lebih memilih minimal lima node. Tentunya, ini berdasarkan pengalaman dan pertimbangannya, bukan ketentuan wajib dari Ceph.

    Pembahasan tersebut mengingatkan saya pada pengujian yang pernah saya lakukan menggunakan dua node Proxmox VE dengan Ceph Squid 19.2. Saat itu, saya menggunakan enam OSD dengan konfigurasi pool size 2 dan min_size 1.

    Saya juga sempat melakukan pengujian dengan mematikan salah satu node untuk melihat dampaknya terhadap cluster. Hasilnya, VM yang sudah berjalan masih dapat beroperasi, tetapi pembuatan VM baru mengalami kendala karena cluster Proxmox kehilangan quorum.

    Perlu dibedakan bahwa kendala tersebut berasal dari quorum Proxmox (Corosync), bukan langsung dari Ceph. Keduanya memiliki mekanisme quorum yang berbeda. Saya kemudian mencoba menambahkan Ceph MON eksternal dan mempelajari penggunaan QDevice untuk membantu quorum Proxmox.

    Dari pengujian tersebut dan artikel yang saya baca, saya memahami bahwa penggunaan cluster dengan jumlah node sedikit memang perlu diperhatikan, terutama ketika salah satu node down dan mengalami kegagalan.

    Pengujian saya sebelumnya masih sebatas lab untuk memahami mekanisme Proxmox dan Ceph. Namun, pengalaman tersebut cukup membantu saya memahami pembahasan dalam artikel bahwa cluster yang berhasil berjalan belum tentu langsung siap digunakan untuk production, terutama jika belum diuji bagaimana kondisinya ketika terjadi kegagalan node atau storage.

    Bacaan:

    https://www.mrplanb.com/blog/proxmox-production-workloads-real-world-scale

  • Mengatasi Gagal Menambahkan Host KVM di CloudStack

    Mengatasi Gagal Menambahkan Host KVM di CloudStack

    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.

    1. Periksa konfigurasi agent

    Jalankan pada host KVM:

    grep '^host=' /etc/cloudstack/agent/agent.properties

    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.

    Dokumentasi: Konfigurasi agent.properties — Apache CloudStack

  • Extract dan Compress File dengan Python

    Extract dan Compress File dengan Python

    Hari ini saya kembali testing instalasi CloudStack di Rocky Linux 9.8 tanpa akses internet. Kebutuhan instalasinya sudah saya kumpulkan dalam satu bundle .tgz.

    Biasanya saya menggunakan tar untuk extract file. Namun, paket ini belum tersedia pada instalasi minimal yang saya pakai, sementara akses ke repository online juga tidak tersedia.

    Karena Python sudah ada di server, saya mencoba mengekstrak bundle menggunakan modul bawaannya, yaitu tarfile.

    Extract file

    Bundle berada di /srv. Saya menyiapkan folder tujuan, lalu menjalankan:

    cd /srv
mkdir -p /srv/coba
python3 -m tarfile -e cloudstack-bundle-4.23-rocky9.8-x86_64.tgz /srv/coba
echo $?

    Opsi -e digunakan untuk extract. Jalankan echo $? langsung setelah perintah tersebut; nilai 0 berarti perintah selesai tanpa kegagalan.

    Untuk mengecek hasilnya:

    ls -lah /srv/coba

    Warning saat extract

    Saat menjalankan perintah tadi, muncul warning:

    RuntimeWarning: The default behavior of tarfile extraction has been changed to disallow common exploits (including CVE-2007-4559).

    Pesan ini menjelaskan adanya pembatasan keamanan saat extract. Tujuannya mencegah isi arsip menulis file ke luar folder tujuan, misalnya melalui path ../../. Beberapa bit permission khusus juga dibersihkan.

    Warning tersebut belum berarti bundle rusak atau proses extract gagal. Cek status perintah dan hasil ekstraksinya. Jika ada error atau traceback setelahnya, periksa pesan tersebut karena proses bisa berhenti sebelum semua file selesai diekstrak.

    Compress folder

    Untuk membuat arsip dengan kompresi gzip, misalnya dari folder /srv/cloudstack-bundle:

    cd /srv
python3 -m tarfile -c cloudstack-bundle-backup.tar.gz cloudstack-bundle

    Opsi -c digunakan untuk membuat arsip. cloudstack-bundle-backup.tar.gz adalah file hasil, sedangkan cloudstack-bundle adalah folder sumber. Sesuaikan nama folder dengan yang ingin dikemas.

    Gunakan .tar.gz untuk kompresi gzip. Jika memakai .tar, file hanya dikemas tanpa kompresi.

    Untuk melihat isi arsip tanpa extract:

    python3 -m tarfile -l cloudstack-bundle-backup.tar.gz

    Dokumentasi: Dokumentasi tarfile Python dan artikel Red Hat yang dicantumkan pada warning.

  • Membuat Metadata Repository Lokal dengan createrepo_c

    Membuat Metadata Repository Lokal dengan createrepo_c

    Saat menyiapkan repository lokal untuk lab CloudStack, saya perlu mengumpulkan package RPM di server staging agar instalasi ke server target bisa dilakukan tanpa akses internet. Setelah package terkumpul, langkah berikutnya adalah membuat metadata menggunakan createrepo_c.

    Fungsi createrepo_c

    createrepo_c adalah tool untuk membuat metadata repository dari kumpulan file RPM. Metadata ini menjadi indeks yang digunakan DNF untuk mengetahui package yang tersedia, versi, lokasi file, dan dependensi.

    Gampangnya sih, RPM adalah packagenya, sedangkan metadata adalah daftar informasi package tersebut. Hasil prosesnya disimpan dalam direktori repodata. Debian Manpages

    Untuk kebutuhan offline, package beserta dependensinya harus disiapkan terlebih dahulu sebelum metadata dibuat.

    Contoh penggunaan di Rocky Linux 9

    Jalankan perintah berikut sebagai root. Contoh ini menggunakan direktori /srv/repo-lokal yang sudah berisi package RPM.

    1. Install createrepo_c

    Lakukan saat repository sumber masih dapat diakses:

    dnf install -y createrepo_c

    Paket ini menyediakan perintah untuk membuat metadata repository. Documentation

    2. Buat metadata repository

    Periksa file RPM yang tersedia:

    ls /srv/repo-lokal/*.rpm

    Kemudian jalankan:

    createrepo_c /srv/repo-lokal

    Perintah tersebut membaca informasi paket dan membuat direktori repodata. Untuk memeriksa hasilnya:

    ls /srv/repo-lokal/repodata/

    Salah satu file yang akan tersedia adalah repomd.xml, yang menjadi acuan metadata repository. Debian Manpages

    Agar bisa digunakan oleh DNF, repository tersebut juga perlu didaftarkan melalui file konfigurasi .repo.

    Jika ada package baru atau perubahan

    Setelah menambah, mengganti, atau menghapus RPM, perbarui metadata:

    createrepo_c --update /srv/repo-lokal

    Opsi --update memanfaatkan metadata lama untuk paket yang tidak berubah, sehingga prosesnya dapat lebih cepat. Informasi paket baru dan perubahan isi repository akan masuk ke metadata terbaru. Debian Manpages

    Pada server, refresh cache DNF. Misalnya repository tersebut sudah terdaftar dengan ID repo-lokal:

    dnf --disablerepo='*' --enablerepo=repo-lokal --refresh makecache

    createrepo_c --update memperbarui indeks di sisi repository, sedangkan dnf makecache memperbarui cache metadata di sisi pengguna. Instalasi atau upgrade paket tetap dilakukan melalui perintah DNF yang sesuai. DNF @DNF_VERSION@-1 documentation

  • OpenDKIM, Selector, dan Perbedaan RSA Key Size

    OpenDKIM, Selector, dan Perbedaan RSA Key Size

    OpenDKIM

    OpenDKIM merupakan aplikasi open-source yang digunakan untuk menambahkan tanda tangan digital pada email menggunakan metode DomainKeys Identified Mail (DKIM).

    Tujuannya adalah membantu server penerima memastikan bahwa email telah ditandatangani menggunakan private key yang sesuai dengan domain penandatangan dan bahwa bagian email yang dilindungi tidak mengalami perubahan selama pengiriman.

    OpenDKIM umumnya digunakan bersama mail server seperti Postfix, termasuk pada infrastruktur SMTP Relay dan mail gateway.

    Cara Kerja OpenDKIM

    Secara sederhana, proses DKIM bekerja sebagai berikut:

    1. Email dikirim: Mail server memproses email keluar.
    2. DKIM Signing: OpenDKIM menandatangani email menggunakan private key.
    3. Verifikasi: Server penerima mengambil public key dari DNS untuk memverifikasi tanda tangan.
    4. Hasil: Jika tanda tangan valid, pemeriksaan DKIM menghasilkan status pass.

    DKIM membantu memverifikasi keaslian tanda tangan email, tetapi tidak secara otomatis menjamin email bebas dari spam.

    DKIM Selector

    Salah satu komponen penting dalam OpenDKIM adalah selector. Selector merupakan nama yang digunakan untuk mengidentifikasi pasangan private key dan public key dalam sebuah domain.

    Contohnya, domain example.com menggunakan selector bernama mail. Maka DNS record DKIM berada pada:

    mail._domainkey.example.com

    Satu domain dapat memiliki beberapa selector, misalnya:

    • default._domainkey.example.com
    • mail._domainkey.example.com
    • relay._domainkey.example.com

    Dengan beberapa selector, setiap mail server dapat menggunakan pasangan key berbeda tanpa harus menggunakan domain yang berbeda.

    RSA Key Size pada DKIM

    Ketika membuat DKIM key, kita dapat menentukan ukuran RSA key yang digunakan. Beberapa ukuran yang dikenal adalah 512-bit, 1024-bit, 2048-bit, dan 4096-bit. Ukuran ini merupakan panjang RSA key, bukan ukuran selector.

    RSA Key SizeKeterangan
    512-bitTidak aman dan tidak diperbolehkan oleh standar DKIM saat ini
    1024-bitUkuran minimum yang diperbolehkan
    2048-bitDirekomendasikan karena keamanan lebih kuat
    4096-bitLebih besar dan didukung untuk verifikasi, tetapi umumnya tidak diperlukan

    Contoh Membuat DKIM Key 2048-bit

    Pada server yang sudah memiliki OpenDKIM Tools, kita dapat membuat RSA key 2048-bit menggunakan perintah:

    opendkim-genkey -b 2048 -s mail -d example.com

    Keterangan:

    • -b 2048 menentukan ukuran RSA key.
    • -s mail menentukan selector.
    • -d example.com menentukan domain.

    Perintah tersebut menghasilkan dua file:

    • mail.private — private key untuk menandatangani email.
    • mail.txt — berisi DNS TXT record untuk publikasi public key.

    Public key dipublikasikan melalui DNS, sedangkan private key disimpan dan digunakan oleh OpenDKIM.

    Kesimpulan

    OpenDKIM merupakan salah satu solusi untuk menerapkan DKIM signing pada mail server. Dalam konfigurasinya, terdapat dua hal yang perlu dibedakan, yaitu selector sebagai identitas key dan RSA key size sebagai ukuran kunci kriptografi.

    RSA 512-bit sudah tidak memenuhi standar keamanan DKIM saat ini. Sementara itu, RSA 1024-bit masih diperbolehkan sebagai ukuran minimum, tetapi RSA 2048-bit lebih direkomendasikan untuk konfigurasi baru.

    Referensi:

  • Membangun CloudStack Menggunakan Repo Lokal

    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.

  • Catatan Webinar NAKIVO v11.3 Beta

    Catatan Webinar NAKIVO v11.3 Beta

    Kemarin saya mengikuti webinar partner training yang membahas pembaruan NAKIVO Backup & Replication v11.3 Beta. Dari beberapa fitur yang diperkenalkan, saya lebih memperhatikan bagian Proxmox karena platform ini cukup sering saya gunakan di lab.

    Pembaruan yang paling saya kenal yaitu migrasi VM dari VMware, pengelolaan backup, dan recovery ketika VM utama bermasalah.

    1. Migrasi VMware ke Proxmox VE

    NAKIVO memperkenalkan kemampuan memulihkan backup VM VMware menjadi VM Proxmox VE. Artinya, backup yang sudah tersedia dapat digunakan sebagai jalur migrasi antarplatform.

    Gambaran alurnya:

    1. VM VMware memiliki backup di NAKIVO.
    2. Backup tersebut digunakan sebagai sumber recovery.
    3. VM dipulihkan ke lingkungan Proxmox VE.

    Ini menarik karena memberikan pilihan pemindahan VM melalui backup tanpa membangun ulang VM dari awal. Pembahasannya juga dekat dengan kegiatan saya yang sedang mempelajari migrasi dari VMware ke platform berbasis KVM.

    2. Disaster Recovery untuk Proxmox

    Dukungan Proxmox diperluas dengan failover, failback, dan Site Recovery. Ketiganya memiliki fungsi yang saling melengkapi:

    • Failover: menjalankan layanan dari VM replica ketika VM utama tidak tersedia.
    • Failback: mengembalikan layanan dari lingkungan pemulihan ke sistem utama setelah siap digunakan.
    • Site Recovery: menyusun dan menjalankan proses pemulihan beberapa VM sesuai urutan yang ditentukan.

    Contohnya, jika suatu aplikasi membutuhkan beberapa VM, urutan pemulihannya dapat disusun dalam recovery plan. Pengujian disaster recovery juga dapat dijadwalkan atau dijalankan sesuai kebutuhan.

    Bagian ini relevan untuk memahami bagaimana VM replica digunakan saat terjadi gangguan, sekaligus bagaimana proses kembali ke sistem utama diatur.

    3. Backup Proxmox Berdasarkan Policy

    Fitur policy-based data protection diperluas ke Proxmox VE. Administrator dapat membuat aturan agar VM yang memenuhi kriteria otomatis masuk ke job backup dan replication.

    Manfaatnya untuk pengelolaan VM:

    • Mengurangi penambahan VM ke job secara manual.
    • Membantu menjaga cakupan backup ketika jumlah VM bertambah.
    • Mengurangi pekerjaan penyesuaian job saat lingkungan berubah.

    Fitur ini lebih terasa manfaatnya ketika VM sudah cukup banyak dan pengelolaan job satu per satu mulai merepotkan.

    4. Pembaruan Lainnya

    Selain bagian Proxmox, webinar juga memperkenalkan:

    • Ransomware Detection: pemindaian backup untuk membantu mengidentifikasi recovery point tanpa ancaman yang terdeteksi.
    • HPE VM Essentials: tambahan dukungan backup dan recovery untuk platform tersebut.
    • IBM AIX: dukungan backup dan recovery file serta folder.

    Ada juga pembahasan perpindahan Exchange Online dari EWS ke Microsoft Graph API. Dukungan Graph API sudah diperkenalkan pada v11.2.3 dan kembali dibahas untuk kelangsungan backup Microsoft 365.

    Catatan: pada materi webinar, akses v11.3 Beta masih tertulis Coming Soon dan melalui undangan. Fitur yang dibahas masih berupa preview.

  • Script Perbaikan Ceph untuk Libvirt dan Agent CloudStack (Rocky Linux 9)

    Script Perbaikan Ceph untuk Libvirt dan Agent CloudStack (Rocky Linux 9)

    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.

    Unduh script

    wget https://raw.githubusercontent.com/rafiharli/cloudstack-ceph-rbd-fix/refs/heads/main/fix-libvirt-rbd.sh

wget https://raw.githubusercontent.com/rafiharli/cloudstack-ceph-rbd-fix/refs/heads/main/fix-cloudstack-agent-rbd.sh

    Jalankan Bagian A

    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:

    sudo bash fix-cloudstack-agent-rbd.sh rollback
sudo bash fix-libvirt-rbd.sh rollback

    Update paket dapat menimpa patch lokal. Periksa kembali setelah update. Detail backup dan pemakaian tersedia di README repository.