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.
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.
Halo! Jadi begini ceritanya, beberapa waktu lalu saya ada list tugas untuk migrate beberapa VM dari VMware ESXi ke Proxmox. Awalnya saya pikir ini bakal ribet banget, tapi ternyata setelah dicoba, prosesnya cukup mudah kok. Walaupun awalnya saya salah menafsirkan untuk import VM.
Nah, di artikel ini saya mau share cara yang menurut saya paling mudah dan aman untuk import VM dari VMware ke Proxmox. Saya akan fokus ke satu metode saja supaya kalian nggak bingung dengan terlalu banyak pilihan.
Kebutuhan
Sebelum mulai, pastikan kalian sudah punya:
Akses ke VMware ESXi/vCenter
Username dan password (minimal user biasa, tapi lebih baik root)
Bisa login ke web interface
Proxmox yang sudah jalan
Minimal 1 node (di tutorial ini saya pakai 3 node)
Storage dengan space yang cukup
Koneksi internet atau network yang stabil
Untuk download/transfer file VM
Langkah 1 — Tambahkan Storage ESXi di Datacenter
Masuk ke Datacenter → Storage → Add → ESXi (paling bawah di dropdown).
Masukkan kredensial ESXi kemudian Klik Add. Storage akan otomatis muncul di semua node cluster (VMware (rafi1) dan VMware (rafi2)).
Langkah 2 — Verifikasi Storage Terdaftar
Di sidebar kiri, pastikan sudah muncul:
VMware (rafi1) — dengan ikon cloud
VMware (rafi2) — dengan ikon cloud
Klik salah satu, lalu pilih tab Virtual Guests. Kamu akan melihat dua VM yang tersedia dari ESXi:
ha-datacenter/vmforvmware/Debian12/Debian12.vmx — format vmx
ha-datacenter/vmforvmware/Talos/Talos.vmx — format vmx
Langkah 3 — Mulai Import VM
Pilih baris VM yang ingin di-import (misal Debian12.vmx), lalu klik tombol Import di atas tabel.
Best practice: Pilih storage yang mendukung shared storage cluster.
Langkah 5 — Opsi Live Import (Opsional)
Centang Live Import hanya jika VM di ESXi masih dalam keadaan mati (stopped) dan kamu ingin Proxmox menyalakannya di sisi Proxmox sambil disk disalin di background. Untuk migrasi normal, biarkan tidak dicentang.
Langkah 6 — Klik Import dan Monitor Progress
Klik tombol Import. Proxmox akan mulai menyalin disk image dari ESXi via jaringan. Pantau progress di panel Logs di bagian bawah Proxmox GUI.
THE END. Jadi seperti itu untuk import vm dari vmware yang menurut saya cara tercepat.
