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:
Siapkan lingkungan tujuan, meliputi OpenNebula, host KVM, datastore, dan jaringan.
Siapkan VM sumber, melalui akses vCenter atau file OVA hasil ekspor.
Jalankan konversi menggunakan OneSwap, lalu impor hasilnya ke datastore dan buat template VM di OpenNebula.
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.
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:
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:
Komponen
Yang diperiksa
Host
Host KVM lokal sudah terdaftar dan terpantau
Datastore
Datastore lokal tersedia
Virtual network
Jaringan yang dibuat miniONE tersedia
Image
Alpine Linux 3.20 sudah siap
Template
Template 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.
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:
VM VMware memiliki backup di NAKIVO.
Backup tersebut digunakan sebagai sumber recovery.
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.
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.
