Cerita Migrasi VM dari Proxmox ke XCP-ng Lewat Xen Orchestra

Pernah nggak sih kalian mau memindahkan VM dari satu hypervisor ke hypervisor lain, lalu berpikir prosesnya cuma tinggal export dan import? Saya juga awalnya berpikir begitu, sampai akhirnya benar-benar menjalaninya sendiri. Kali ini saya perlu memindahkan sebuah VM Ubuntu dari Proxmox VE menuju XCP-ng yang dikelola lewat Xen Orchestra Appliance, atau biasa disebut XOA.

Yang bikin menarik, VM yang dipindahkan bukan VM kosong. Di dalamnya sudah ada aplikasi yang berjalan, konfigurasi IP statis, LVM, sampai data produksi, jadi prosesnya harus dilakukan dengan hati-hati. Belum lagi Proxmox memakai disk QCOW2 sedangkan XCP-ng memakai VHD pada Storage Repository berbasis file, sehingga migrasinya bukan sekadar menyalin file. Jadi begini cerita lengkapnya.

Apa yang Perlu Disiapkan?

Sebelum mulai, ada beberapa akses dan syarat yang harus tersedia. Saya butuh SSH ke Proxmox untuk mencari lokasi disk, menjalankan konversi, dan mengirim file. Saya juga butuh SSH ke host XCP-ng untuk memeriksa storage, memperbaiki VHD, dan melakukan scan. Perlu dicatat, yang dibutuhkan adalah SSH ke host XCP-ng, bukan ke VM XOA, karena XOA hanya berfungsi sebagai management layer sedangkan file disk masuk ke Storage Repository milik XCP-ng.

Selain itu, dashboard Xen Orchestra dipakai untuk membuat VM baru dan memasang disk hasil migrasi. Saya juga menyiapkan storage sementara yang bisa ditulis dan berkapasitas cukup, backup VM yang wajib tersedia sebelum disk produksi diproses, serta memastikan koneksi jaringan Proxmox bisa mengakses port 22 milik host XCP-ng.

Alur Migrasinya Seperti Apa?

Secara sederhana, workflow yang saya gunakan seperti ini:

Backup VM
    ↓
Matikan VM di Proxmox
    ↓
Konversi QCOW2 menjadi VHD
    ↓
Transfer VHD ke XCP-ng
    ↓
Daftarkan VHD sebagai VDI
    ↓
Buat VM lewat Xen Orchestra
    ↓
Attach disk
    ↓
Perbaiki firmware dan jaringan

Kelihatannya simpel, kan? Kenyataannya saya menemukan beberapa kendala di tengah jalan, dan justru bagian itu yang jadi paling menarik dari migrasi ini.

Langkah 1: Mengenali VM di Proxmox

Sebelum memindahkan apa pun, saya memeriksa dulu konfigurasi VM supaya tahu persis apa yang sedang saya hadapi.

qm status <VMID>
qm config <VMID>

Dari sini saya mendapatkan informasi penting seperti jumlah CPU, RAM, lokasi disk, jenis network adapter, dan firmware yang digunakan. VM ini ternyata cukup gemuk, dengan 8 vCPU, RAM 32 GB, disk 100 GB dalam format QCOW2, sistem operasi Ubuntu Server 24.04, firmware Legacy BIOS, dan network adapter VirtIO. Detail seperti firmware dan network adapter ini kelihatannya sepele, tapi nanti justru jadi penentu.

Lokasi asli disk kemudian saya cari menggunakan perintah berikut:

pvesm path <STORAGE>:<VMID>/vm-<VMID>-disk-0.qcow2

Hasilnya mengarah ke NFS storage yang terpasang pada Proxmox:

/mnt/pve/<SOURCE-STORAGE>/images/<VMID>/vm-<VMID>-disk-0.qcow2

Setelah itu saya masuk ke Ubuntu untuk memeriksa filesystem, isi /etc/fstab, dan yang paling penting, dukungan driver Xen di kernelnya.

lsblk -o NAME,SIZE,FSTYPE,TYPE,MOUNTPOINTS
findmnt /
cat /etc/fstab

grep -E 'CONFIG_XEN_(BLKDEV_FRONTEND|NETDEV_FRONTEND)=' 
  /boot/config-$(uname -r)

Untungnya kernel Ubuntu sudah memiliki xen-blkfront dan xen-netfront. Artinya disk dan network adapter milik XCP-ng seharusnya bisa dikenali setelah VM dipindahkan, jadi saya bisa lanjut dengan tenang.

Langkah 2: Backup dan Matikan VM

Sebelum migrasi dimulai, saya membuat full backup ke Proxmox Backup Server. Ini bukan langkah formalitas, karena selama proses saya akan mengonversi disk, membuat ulang VM, dan mengubah konfigurasi jaringan. Kalau ada yang meleset, VM lama masih bisa dikembalikan tanpa drama.

Setelah backup selesai, VM saya matikan secara normal, lalu saya pastikan statusnya benar-benar berhenti sebelum menyentuh disknya.

qm shutdown <VMID>
qm status <VMID>

Proses baru saya lanjutkan setelah status VM menunjukkan status: stopped. VM harus benar-benar mati supaya tidak ada perubahan data ketika disk sedang dikonversi.

Langkah 3: Mencari Storage untuk Hasil Konversi

Awalnya saya ingin menyimpan hasil konversi pada NFS storage yang biasa dipakai untuk ISO, karena kapasitasnya masih besar. Tapi begitu saya coba membuat direktori, muncul error yang langsung menghentikan rencana itu:

mkdir: cannot create directory: Read-only file system

Ternyata NFS tersebut dipasang dalam mode read only. Ruangnya memang lega, tapi jelas tidak bisa dipakai sebagai lokasi staging. Akhirnya saya beralih ke NFS lain yang memang bisa ditulis, lalu memastikan kapasitasnya cukup.

mkdir -p /mnt/pve/<WRITABLE-NFS>/migration
df -h /mnt/pve/<WRITABLE-NFS>

Dari sini saya belajar satu hal sederhana tapi sering terlupa, bahwa ruang kosong saja tidak cukup, kita juga harus memastikan storagenya benar-benar bisa ditulis.

Langkah 4: Konversi QCOW2 Menjadi VHD

Disk dari Proxmox kemudian saya konversi menjadi dynamic VHD menggunakan qemu-img. Opsi -p saya tambahkan supaya progress konversinya terlihat di terminal, biar tidak menebak-nebak apakah prosesnya jalan atau menggantung.

qemu-img convert -p 
  -f qcow2 
  -O vpc 
  -o subformat=dynamic 
  /mnt/pve/<SOURCE-STORAGE>/images/<VMID>/vm-<VMID>-disk-0.qcow2 
  /mnt/pve/<WRITABLE-NFS>/migration/server-xcpng.vhd

Setelah selesai, hasilnya saya periksa untuk memastikan formatnya benar.

qemu-img info 
  /mnt/pve/<WRITABLE-NFS>/migration/server-xcpng.vhd

Virtual size disknya tetap sekitar 100 GB, tapi ukuran file fisiknya hanya sekitar 40 GB karena memakai format dinamis. Selisih ini yang nanti bikin urusan transfer jadi lebih ringan.

Langkah 5: Menentukan Storage Tujuan

Berikutnya saya masuk ke host XCP-ng melalui SSH.

ssh root@<XCPNG-IP>

Sempat terpikir untuk menaruh file VHD di /root biar praktis. Tapi setelah menjalankan df -h, ternyata ruang kosong pada filesystem root cuma sekitar 15 GB, jelas tidak cukup untuk menampung file VHD berukuran 40 GB. Jadi saya cari Storage Repository yang kapasitasnya memadai.

xe sr-list 
  params=uuid,name-label,type,physical-size,physical-utilisation

Pilihan akhirnya jatuh ke storage lokal 4 TB bertipe ext. Karena SR tersebut berbasis file, lokasi mountnya berada di /run/sr-mount/<SR-UUID>, dan di sanalah file disk nanti akan bersarang.

Langkah 6: Mengirim VHD Langsung ke XCP-ng

Cara yang lebih umum sebenarnya adalah mengimpor disk lewat menu Import Disk di Xen Orchestra. Tapi karena keterbatasan ruang staging tadi, saya memilih mengirim file langsung dari Proxmox menuju SR XCP-ng. Metode ini memang lebih berisiko, karena nama file VHD wajib memakai format <UUID>.vhd, dan kalau namanya salah, SR bisa menampilkan error atau warning.

Supaya aman, saya buat dulu UUID baru di XCP-ng, baru kemudian mengirim filenya dengan nama yang benar.

uuidgen

scp 
  /mnt/pve/<WRITABLE-NFS>/migration/server-xcpng.vhd 
  root@<XCPNG-IP>:/run/sr-mount/<SR-UUID>/<DISK-UUID>.vhd

Dengan cara ini file berpindah langsung dari Proxmox menuju storage XCP-ng tanpa mampir ke filesystem root. Dan begitu saja, masalah kapasitas staging yang tadi bikin pusing langsung selesai.

Langkah 7: Memeriksa dan Mendaftarkan VHD

Setelah transfer selesai, saya tidak langsung percaya filenya utuh. Saya bandingkan dulu checksum di kedua server, mulai dari sisi Proxmox lalu sisi XCP-ng.

sha256sum 
  /mnt/pve/<WRITABLE-NFS>/migration/server-xcpng.vhd

sha256sum 
  /run/sr-mount/<SR-UUID>/<DISK-UUID>.vhd

Perhitungan SHA-256 untuk file sebesar ini memang lumayan lama dan tidak menampilkan progress, jadi butuh sedikit kesabaran. Yang penting, hasil checksum di kedua server harus sama persis. Setelah cocok, VHD saya perbaiki dan periksa validitasnya.

vhd-util repair 
  -n /run/sr-mount/<SR-UUID>/<DISK-UUID>.vhd

vhd-util check 
  -n /run/sr-mount/<SR-UUID>/<DISK-UUID>.vhd

Begitu dinyatakan valid, saya scan ulang SR-nya supaya XCP-ng mengenali disk baru tersebut, lalu mencari VDI-nya berdasarkan UUID.

xe sr-scan uuid=<SR-UUID>

xe vdi-list 
  location=<DISK-UUID> 
  params=uuid,name-label,location,virtual-size,physical-utilisation

Dan benar saja, disknya akhirnya muncul di Xen Orchestra dan siap dipasang ke VM baru.

Langkah 8: Membuat VM di Xen Orchestra

Saya membuat VM baru lewat Xen Orchestra dengan spesifikasi yang sama seperti VM lama, lalu menghapus disk bawaannya dan memasang VDI hasil migrasi lewat menu VM → Disks → Attach an existing disk. Sampai sini rasanya tinggal menyalakan dan beres.

Ternyata tidak semudah itu. Ketika VM dinyalakan, sistemnya malah masuk ke PXE boot. Sempat saya kira disk hasil konversinya rusak dan semua kerja tadi sia-sia, tapi setelah ditelusuri, masalahnya ada pada firmware. VM baru memakai UEFI, sedangkan VM lama di Proxmox memakai legacy BIOS. Begitu firmware saya ubah menjadi BIOS, Ubuntu langsung berhasil boot. Dari sini saya sadar, hal kecil seperti pilihan BIOS atau UEFI bisa menentukan apakah seluruh migrasi dianggap gagal atau berhasil.

Langkah 9: Memperbaiki Jaringan Ubuntu

Ubuntu sudah hidup, tapi alamat IP-nya tidak muncul. Penyebabnya ternyata nama interface yang berubah. Di Proxmox namanya ens18, dan setelah pindah ke XCP-ng namanya ikut berganti, sementara Netplan masih setia mencoba memasang IP ke ens18 yang sudah tidak ada. Jadi saya periksa dulu nama interface barunya lewat console.

ip -br link
ip -br addr

Setelah konfigurasi Netplan saya sesuaikan, IP-nya langsung aktif kembali. Supaya lebih tahan terhadap perubahan nama interface di kemudian hari, saya mencocokkan konfigurasi berdasarkan MAC address, bukan lagi bergantung pada nama interface.

network:
  version: 2
  ethernets:
    lan0:
      match:
        macaddress: "AA:BB:CC:DD:EE:FF"
      addresses:
        - "<SERVER-IP>/<PREFIX>"
      routes:
        - to: default
          via: "<GATEWAY-IP>"

Setelah itu konfigurasinya saya generate dan uji sebelum benar-benar diterapkan, dan VM pun kembali bisa diakses lewat SSH.

netplan generate
netplan try

Langkah 10: Guest Tools dan Pemeriksaan Akhir

Langkah terakhir adalah memasang XCP-ng Guest Tools supaya integrasi VM dengan hypervisor-nya berjalan mulus.

apt update
apt install -y xe-guest-utilities
systemctl enable --now xe-linux-distribution

Setelah itu saya melakukan pemeriksaan menyeluruh, mulai dari filesystem, jaringan, service, sampai log Ubuntu, untuk memastikan tidak ada yang diam-diam bermasalah.

lsblk -f
findmnt /
df -hT
ip -br addr
ip route
systemctl --failed
journalctl -p err -b --no-pager

Karena VM ini menjalankan layanan email, saya tidak berhenti di level sistem operasi. Pengujian saya lanjutkan sampai level aplikasi, mulai dari akses webmail, pengiriman email internal dan eksternal, DNS, sertifikat TLS, sampai antrean email. Selama masa observasi, VM lama di Proxmox sengaja saya biarkan mati, dan backup serta file VHD hasil konversi belum saya hapus, sebagai jaring pengaman kalau ada yang muncul belakangan.

Hasilnya?

Migrasi akhirnya berhasil. Prosesnya memang tidak berjalan sekali klik, karena di sepanjang jalan ada NFS yang read only, ruang root XCP-ng yang terlalu kecil, firmware yang tidak cocok, sampai nama interface jaringan yang berubah. Justru dari semua kendala itu saya semakin yakin bahwa migrasi VM bukan sekadar memindahkan file disk, tapi juga memindahkan pola boot, konfigurasi jaringan, dan seluruh kebiasaan VM dari lingkungan lamanya.

Setupnya memang butuh effort di awal, tapi begitu firmware, disk, dan jaringan sudah cocok, VM bisa berjalan normal di XCP-ng dan dikelola sepenuhnya lewat Xen Orchestra. Kalau kalian pernah melakukan migrasi dari Proxmox ke XCP-ng dengan metode lain, boleh banget berbagi pengalaman di kolom komentar.

TutuLore