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.
Apache CloudStack dapat mengelola VM di Proxmox VE melalui Proxmox Orchestrator Extension. Setelah terintegrasi, proses deploy, start, stop, reboot, delete, snapshot, konfigurasi VLAN, dan akses console dapat dilakukan dari CloudStack.
Panduan ini menggunakan konfigurasi lab yang sudah berhasil menjalankan Ubuntu 24.04 dari template Proxmox.
Topologi dan kondisi awal
Komponen
Konfigurasi
CloudStack Management Server
csmgmt-kvm.lab.local — 192.168.14.135
Versi CloudStack
4.22.1.1
Proxmox node
pvecs1.lab.local — 192.168.14.136
Proxmox API
https://192.168.14.136:8006
Proxmox node name
pvecs1
Storage Proxmox
local-lvm
Guest bridge
vmbr1
Template Proxmox
Ubuntu Server 24.04, VMID 9000
Disk template
20 GiB
Guest network
guest-isolated-01
Guest CIDR
10.1.1.0/24
Guest gateway
10.1.1.1
Guest VLAN
319
Sebelum integrasi dilakukan, kondisi berikut sudah tersedia:
CloudStack Management Server dan zone sudah aktif.
Proxmox VE dapat diakses dari Management Server melalui TCP 8006.
Proxmox dan host tempat CloudStack Virtual Router berjalan terhubung ke jaringan VLAN trunk yang sama.
Bridge vmbr1 sudah VLAN-aware dan terhubung ke uplink guest network.
Template Ubuntu 24.04 VMID 9000 sudah dibuat di Proxmox.
API token khusus CloudStack sudah tersedia.
Dokumentasi resmi menjelaskan bahwa extension Proxmox berkomunikasi dengan Proxmox VE API melalui HTTPS. CloudStack kemudian meneruskan MAC address dan VLAN ID VM ke Proxmox saat deployment. Lihat Proxmox Orchestrator Extension.
1. Menyiapkan template Proxmox
Template pada lab menggunakan Ubuntu 24.04 cloud image dengan VMID 9000. Seluruh pengaturan pada bagian ini dilakukan melalui Proxmox GUI.
Buka:
pvecs1 > VM 9000 > Hardware
Atur hardware template sebagai berikut:
Hardware
Nilai
Processors
2 cores
Memory
2048 MiB
SCSI Controller
VirtIO SCSI single
Hard Disk
scsi0, storage local-lvm, size 20 GiB
CloudInit Drive
Storage local-lvm
Network Device
Model VirtIO, Bridge vmbr1
Display
Standard VGA
Serial Port
socket — opsional
Pastikan VirtIO SCSI single dipilih pada bagian SCSI Controller, bukan Display. Display menggunakan Standard VGA agar console VM dapat ditampilkan melalui CloudStack.
Jika disk masih mengikuti ukuran awal Ubuntu cloud image, pilih:
VM 9000 > Hardware > Hard Disk (scsi0) > Disk Action > Resize
Tambahkan kapasitas sampai total disk menjadi 20 GiB. Proxmox menggunakan nilai penambahan saat melakukan resize, sehingga periksa ukuran saat ini sebelum mengisi kolom Size Increment.
Selanjutnya buka:
VM 9000 > Options
Atur:
Option
Nilai
Boot Order
Aktifkan scsi0 sebagai urutan pertama
QEMU Guest Agent
Enabled
Kemudian buka:
VM 9000 > Cloud-Init
Isi konfigurasi berikut:
Cloud-Init
Nilai
User
ubuntu
Password
Password sementara khusus lab
SSH Public Key
Public key administrator
IP Config
DHCP
Gunakan SSH key untuk produksi dan hindari password tetap yang sama pada seluruh hasil clone.
Setelah konfigurasi selesai, matikan VM kemudian klik kanan VM 9000 dan pilih Convert to template. VMID 9000 selanjutnya digunakan sebagai template_id di CloudStack.
2. Memastikan jaringan guest siap
Bridge vmbr1 harus membawa VLAN guest dari Proxmox menuju jaringan CloudStack. Buka:
pvecs1 > System > Network
Jika vmbr1 belum tersedia, pilih Create > Linux Bridge, kemudian isi:
Field
Nilai
Name
vmbr1
IPv4/CIDR
Kosong
Gateway (IPv4)
Kosong
Bridge ports
Interface atau bond untuk trunk guest
VLAN aware
Aktif
Autostart
Aktif
Klik Create, lalu Apply Configuration. Jika vmbr1 sudah tersedia, pilih bridge tersebut dan klik Edit untuk memastikan VLAN aware sudah aktif.
VLAN 319 harus diizinkan pada switch fisik, uplink Proxmox, dan host CloudStack yang menjalankan Virtual Router. Pastikan perubahan bridge dilakukan melalui interface management yang berbeda agar akses ke Proxmox tidak terputus.
3. Membuat API token Proxmox
Buka Proxmox UI, lalu masuk ke:
Datacenter > Permissions > API Tokens
Buat token khusus untuk CloudStack. Simpan tiga informasi berikut:
Field
Contoh
User
cloudstack@pve
Token ID
cloudstack
Secret
<PROXMOX_API_SECRET>
Untuk lab, Privilege Separation dapat dinonaktifkan. Untuk produksi, aktifkan pemisahan privilege dan berikan role yang diperlukan pada path /vms, /storage, dan /sdn.
Respons yang benar berisi informasi versi Proxmox pada objek data.
4. Menyiapkan Proxmox Extension di Management Server
Extension bawaan berada pada direktori berikut:
script=/usr/share/cloudstack-management/extensions/Proxmox/proxmox.sh
test -x "$script"
bash -n "$script"
Penyesuaian kompatibilitas pada instalasi lab
Skrip yang digunakan pada lab dinormalisasi agar dapat membaca detail resource dari payload CloudStack 4.22.1.1 dan menggunakan URL Proxmox dalam format lengkap.
Backup skrip terlebih dahulu:
cp -a "$script" "${script}.before-integration"
Pada fungsi parse_json(), detail host dibuat menerima nilai dari host maupun resourcemap, termasuk variasi nama objek externaldetails dan externalDetails. Pola hasil akhirnya sebagai berikut:
Dengan format tersebut, nilai url yang dimasukkan ke CloudStack harus lengkap:
https://192.168.14.136:8006
Validasi skrip setelah disesuaikan:
chmod 0755 "$script"
bash -n "$script"
Jika terdapat beberapa Management Server, gunakan file yang sama pada seluruh node agar status extension tetap Ready. CloudStack memang memeriksa keberadaan dan konsistensi file extension pada Management Server.
5. Mengaktifkan Proxmox Extension
Masuk ke CloudStack UI sebagai administrator:
Extensions > Proxmox > Enable
Pastikan status extension menjadi:
Enabled / Ready
CloudStack 4.22 menyediakan extension Proxmox sebagai orchestrator berbasis shell script. File extension ditempatkan di bawah /usr/share/cloudstack-management/extensions/ dan dipanggil menggunakan payload JSON untuk setiap operasi VM. Lihat mekanisme Extensions CloudStack.
Simpan cluster, kemudian lanjutkan dengan menambahkan host Proxmox.
7. Menambahkan Proxmox sebagai host CloudStack
Tambahkan host pada cluster External yang baru dibuat. Gunakan detail berikut:
Detail
Nilai
Host name
pvecs1.lab.local
url
https://192.168.14.136:8006
user
cloudstack@pve
token
cloudstack
secret
<PROXMOX_API_SECRET>
node
pvecs1
network_bridge
vmbr1
verify_tls_certificate
false untuk sertifikat self-signed pada lab
node harus sama dengan nama node yang digunakan oleh Proxmox API, bukan sekadar nama tampilan di CloudStack. Nama tersebut dapat dilihat pada panel kiri Proxmox GUI, tepat di bawah Datacenter. Pada lab ini nilainya adalah pvecs1.
Setelah host ditambahkan, pastikan statusnya:
State: Up
Resource State: Enabled
Untuk produksi, gunakan sertifikat TLS yang dipercaya dan set verify_tls_certificate=true.
URL hanya menjadi metadata karena image yang digunakan sudah berada di Proxmox.
Tambahkan External Details berikut:
Key
Value
template_type
template
template_id
9000
CloudStack mendukung pemetaan template CloudStack ke template atau ISO Proxmox. Untuk deployment dari template, gunakan template_type=template dan isi template_id dengan VMID template Proxmox.
Menyamakan metadata ukuran template
Template pada lab memiliki root disk 20 GiB. Nilai byte-nya adalah:
SELECT id, name, size, hypervisor_type
FROM vm_template
WHERE name = 'ubuntu-2404-cloudstack'
AND removed IS NULL;
Set ukuran sesuai disk template Proxmox:
UPDATE vm_template
SET size = 21474836480
WHERE id = <ID_TEMPLATE>
AND hypervisor_type = 'External'
AND removed IS NULL;
Verifikasi:
SELECT id, name, size,
ROUND(size / 1073741824, 2) AS size_gib
FROM vm_template
WHERE id = <ID_TEMPLATE>;
Nilai size_gib harus menunjukkan 20.00.
9. Menyiapkan Compute Offering
Buat Compute Offering untuk VM Proxmox, misalnya:
Field
Nilai
Name
proxmox-small
CPU
2
CPU speed
1000 MHz
Memory
2048 MB
Root Disk Size
20 GB
CPU dan memory dari offering akan diterapkan pada hasil clone. Root Disk Size dibuat sama dengan root disk template agar metadata dan kapasitas instance konsisten.
10. Menyiapkan isolated guest network
Buat atau gunakan network berikut:
Field
Nilai
Name
guest-isolated-01
Network mode
NATTED
CIDR
10.1.1.0/24
Gateway
10.1.1.1
VLAN
319
Pada isolated network mode NATTED, CloudStack Virtual Router menyediakan DHCP, DNS, gateway, dan Source NAT. Dokumentasi CloudStack menjelaskan bahwa VR memberikan alamat IP guest dan meneruskan trafik keluar melalui Source NAT. Lihat CloudStack Guest Traffic.
Jika Network Offering menggunakan Default Egress Policy: Deny, tambahkan Egress Rule agar VM dapat mengakses internet. Untuk lab:
Protocol
CIDR
Port
All
0.0.0.0/0
Semua
Untuk produksi, batasi sesuai kebutuhan, misalnya DNS, HTTP, HTTPS, NTP, dan repository sistem operasi.
11. Melakukan deployment VM
Buka:
Compute > Instances > Add Instance
Pilih:
Zone tempat cluster Proxmox berada.
Template ubuntu-2404-cloudstack.
Compute Offering proxmox-small.
Network guest-isolated-01.
External Details yang dapat ditambahkan saat deployment:
Key
Value
Fungsi
storage
local-lvm
Menentukan storage disk hasil clone
is_full_clone
false
Menggunakan linked clone
vm_name
Opsional
Nama VM di Proxmox
disk_size_gb tidak digunakan untuk deployment dari template. Parameter tersebut digunakan ketika sumber deployment berupa ISO.
CloudStack akan mengambil VMID yang tersedia dari Proxmox, melakukan clone template 9000, menerapkan CPU dan RAM, memasang MAC address CloudStack, menambahkan tag VLAN 319, lalu menyalakan VM.
12. Verifikasi deployment
Dari CloudStack
Pastikan:
Instance State: Running
Host: pvecs1.lab.local
IP Address: 10.1.1.x
Uji operasi berikut dari CloudStack UI:
Console
Stop
Start
Reboot
Delete
Dari Proxmox GUI
Buka node pvecs1, lalu cari VM baru pada panel kiri. Nama VM mengikuti internal name CloudStack, misalnya i-2-13-VM.
Pilih VM tersebut dan periksa:
Menu
Verifikasi
Summary
VM berstatus running
Hardware > Processors
Jumlah core mengikuti Compute Offering
Hardware > Memory
Kapasitas RAM mengikuti Compute Offering
Hardware > Hard Disk
Disk hasil clone berada di local-lvm
Hardware > Network Device
Bridge vmbr1 dan VLAN Tag 319
Console
Tampilan boot Ubuntu dapat dibuka
Dari dalam VM
Login melalui console menggunakan user ubuntu. Pada lab, gunakan password Cloud-Init yang telah ditentukan pada template. Setelah login, jalankan:
ip -br address
ip route
ping -c 3 10.1.1.1
ping -c 3 8.8.8.8
getent ahostsv4 google.com
curl -I https://example.com
Contoh alamat yang diterima VM:
eth0 UP 10.1.1.53/24
default via 10.1.1.1 dev eth0
Hasil tersebut menunjukkan bahwa DHCP, gateway, VLAN trunk, Egress Rule, DNS, dan Source NAT CloudStack sudah bekerja.
Hasil akhir
Setelah seluruh konfigurasi diterapkan:
Host Proxmox tampil Up/Enabled di CloudStack.
Template Proxmox VMID 9000 dapat dipilih dari CloudStack.
VM dibuat otomatis di Proxmox menggunakan VMID baru.
CPU dan memory mengikuti Compute Offering.
NIC VM menggunakan MAC address dan VLAN dari CloudStack.
VM memperoleh IP dari CloudStack Virtual Router.
Console dapat dibuka dari CloudStack UI.
VM dapat mengakses internet setelah Egress Rule diizinkan.
Lifecycle VM dapat dikelola dari CloudStack.
Catatan keamanan untuk produksi
Gunakan API token khusus CloudStack dengan hak minimum yang diperlukan.
Gunakan sertifikat TLS valid dan aktifkan verifikasi sertifikat.
Jangan menaruh token secret di dokumentasi, shell history, atau log publik.
Gunakan SSH key sebagai akses utama VM.
Hindari password default yang sama pada semua VM.
Rotasi API token secara berkala.
Gunakan shared storage jika template harus tersedia pada beberapa node Proxmox.
Backup skrip extension sebelum upgrade CloudStack dan validasi kembali setelah upgrade.
Saat menambahkan host KVM ke Apache CloudStack menggunakan opsi System SSH Key, proses penambahan host gagal karena Management Server tidak dapat melakukan autentikasi SSH.
Error yang Muncul
Pada log CloudStack, error yang muncul mengarah ke kegagalan autentikasi SSH key:
Failed to authenticate with ssh key
Failed to authenticate with ssh key, retrying with password
Pada CloudStack UI, error dapat ditampilkan dalam bentuk:
Could not add host at [http://192.168.14.135] ...
due to: [Authentication error with ssh private key]
Ketika koneksi diuji secara manual, autentikasi SSH juga gagal:
Error tersebut menunjukkan bahwa private key milik CloudStack belum dikenali oleh user root pada host KVM.
Kondisi Lab
Server yang digunakan pada lab ini adalah:
Hostname: csmgmt-kvm.lab.local
IP address: 192.168.14.135
Fungsi: CloudStack Management Server sekaligus host KVM
Autentikasi host: System SSH Key
Walaupun Management Server dan host KVM berada pada server yang sama, CloudStack tetap melakukan koneksi SSH ke:
root@192.168.14.135
Proses CloudStack berjalan menggunakan user sistem cloud. Oleh karena itu, private key yang digunakan harus dapat dibaca oleh user cloud, sedangkan public key-nya harus terdaftar pada /root/.ssh/authorized_keys.
Memeriksa Home Directory User cloud
Jangan langsung menggunakan /var/cloudstack/management karena lokasi home directory user cloud dapat berbeda berdasarkan sistem operasi dan paket CloudStack yang digunakan.
CloudStack memang menyediakan opsi penambahan host KVM menggunakan System SSH Key dengan menempatkan public key Management Server pada /root/.ssh/authorized_keys host KVM. Prosedur tersebut juga dijelaskan dalam dokumentasi konfigurasi Apache CloudStack.
Opsi BatchMode=yes memastikan SSH tidak meminta password. Dengan demikian, keberhasilan perintah tersebut membuktikan bahwa autentikasi benar-benar menggunakan SSH key.
Perhatikan bagian yang menunjukkan apakah private key ditawarkan, diterima, atau ditolak oleh SSH server.
Mengulangi Penambahan Host
Setelah pengujian SSH berhasil, ulangi penambahan host KVM pada CloudStack dengan parameter:
Host Name : 192.168.14.135
Username : root
Authentication: System SSH Key
Konfigurasi berikut tidak diperlukan pada kasus ini:
Defaults:cloud !requiretty
Pengaturan tersebut berkaitan dengan penggunaan sudo oleh user non-root pada host tujuan. Pada kasus ini CloudStack melakukan koneksi langsung sebagai root, sehingga masalahnya murni pada autentikasi SSH key.
Kesimpulan
Penyebab error bukan berasal dari status cloudstack-management, libvirtd, ataupun socket libvirt. Masalahnya adalah System SSH Key CloudStack belum dapat digunakan untuk login sebagai root ke host KVM.
Alur autentikasi yang harus dipastikan adalah:
Proses CloudStack sebagai user cloud
↓
Membaca private key dari home user cloud
↓
SSH ke root@192.168.14.135
↓
Public key ditemukan di /root/.ssh/authorized_keys
↓
Login berhasil tanpa password
Setelah koneksi SSH sebagai user cloud berhasil dan menghasilkan output root, proses penambahan host KVM dapat diulangi menggunakan opsi System SSH Key.
Saya memiliki Proxmox cluster yang terdiri dari pveceph1 dan pveceph2, dengan tiga OSD Ceph pada setiap node. Agar cluster tetap dapat dikelola dan storage Ceph tetap melayani I/O ketika salah satu node mati, saya menambahkan server Debian eksternal bernama cephmon3.
Server tersebut menjalankan dua layanan berbeda:
Ceph MON ketiga untuk menjaga quorum Ceph.
Corosync qnetd untuk memberikan vote QDevice kepada cluster PVE.
Ceph MON tidak menggantikan QDevice karena keduanya menangani quorum yang berbeda.
Topologi
Host
Layanan
pveceph1
PVE, MON, MGR, 3 OSD
pveceph2
PVE, MON, MGR, 3 OSD
cephmon3
Debian, MON, qnetd, tanpa OSD
cephmon3 harus berada pada server atau hypervisor independen. Jangan menyimpannya pada pveceph1, pveceph2, atau pool Ceph yang sama.
1. Memastikan MON dan MGR pada kedua node
Dari GUI Proxmox, buka node > Ceph > Monitor. Pastikan layanan berikut sudah terdaftar:
MON pada pveceph1 dan pveceph2.
MGR pada pveceph1 dan pveceph2, dengan satu active dan satu standby.
Jika ada yang belum tersedia, pilih node terkait lalu klik Create pada bagian Monitor atau Manager.
Lanjutkan ketika kedua MON PVE sudah berada dalam quorum.
2. Menyiapkan server cephmon3
Saya menggunakan Debian 13 minimal dengan 2 vCPU, RAM 4 GB, disk lokal 32 GB, IP statis, SSH server, dan tanpa desktop environment.
Pastikan hostname konsisten:
hostnamectl set-hostname cephmon3
hostnamectl
Tambahkan resolusi hostname ketiga server melalui DNS internal atau /etc/hosts. Pastikan waktu tersinkronisasi:
Jika Debian dipasang menggunakan ISO DVD, nonaktifkan sumber deb cdrom: dan pastikan repository online Debian Trixie sudah aktif sebelum menjalankan apt update.
3. Mengatur firewall (untuk production)
Untuk lingkungan produksi, firewall sebaiknya tetap aktif dan hanya membuka koneksi yang diperlukan:
Port
Arah
Fungsi
TCP 3300 dan 6789
Antara ketiga host MON
Komunikasi Ceph MON
TCP 5403
pveceph1/pveceph2 ke cephmon3
Corosync qnetd
TCP 22
Jaringan administrator ke cephmon3
SSH administrasi
Jika menggunakan Proxmox Firewall, tambahkan rule Ceph pada kedua node PVE dan izinkan IP cephmon3. Pada server Debian, izinkan IP kedua node PVE menuju port MON dan qnetd.
Untuk lab lokal yang terisolasi, firewall dapat dinonaktifkan sementara agar pengujian lebih mudah. Namun, jangan menggunakan cara tersebut pada lingkungan produksi dan aktifkan kembali firewall setelah pengujian selesai.
ID MON harus konsisten. Karena service bernama ceph-mon@cephmon3, direktori datanya harus bernama ceph-cephmon3 dan konfigurasi menggunakan [mon.cephmon3].
Dengan QDevice, pvecm expected 1 tidak perlu digunakan sebagai konfigurasi permanen.
8. Memeriksa konfigurasi pool
Untuk cluster dengan OSD hanya pada dua host, pool dibuat terlebih dahulu dengan size 3/min_size 2, kemudian diedit menjadi size 2/min_size 1 pada pvecephpool dan .mgr.
ceph osd pool get pvecephpool size
ceph osd pool get pvecephpool min_size
ceph osd pool get .mgr size
ceph osd pool get .mgr min_size
Nilai min_size 1 membuat storage tetap menerima I/O dari satu replika ketika satu node OSD mati, tetapi Ceph akan berada dalam kondisi degraded dan risiko kehilangan data meningkat.
9. Melakukan pengujian
Matikan salah satu node PVE melalui GUI, kemudian periksa dari node yang masih hidup:
pvecm status
ceph -s
ceph mon stat
Hasil yang diharapkan:
PVE tetap quorate menggunakan satu node dan QDevice.
Ceph tetap memiliki quorum melalui satu MON PVE dan cephmon3.
VM pada node yang masih hidup tetap berjalan.
Storage tetap dapat menerima I/O, tetapi berstatus degraded sampai node kedua kembali.
VM pada node yang mati hanya dapat otomatis menyala di node lainnya jika telah dikonfigurasi sebagai resource HA dan kapasitas node yang tersisa mencukupi.
Kesimpulan
Penambahan cephmon3 menyelesaikan dua kebutuhan pada cluster dua node: Ceph memperoleh MON ketiga, sedangkan Proxmox memperoleh vote tambahan dari QDevice. Solusi ini dapat menggunakan Debian ringan tanpa menambah node PVE ketiga, tetapi tetap merupakan desain kompromi karena data OSD hanya tersimpan pada dua host.
Beberapa waktu lalu saya diminta melakukan pengujian migrasi NAKIVO Backup & Replication ke server baru. Tujuan pengujian ini adalah memastikan apakah konfigurasi seperti inventory, credentials, job backup, job replikasi, dan schedule dapat dipindahkan tanpa harus dibuat ulang.
Pengujian dilakukan menggunakan dua server, yaitu nakivo sebagai server lama dan nakivo2 sebagai server baru. Inventory yang dikelola terdiri dari dua server Proxmox, yaitu pve-nakivo dan pve-nakivo2, dengan backup tersimpan pada Onboard Repository.
Memahami Cakupan System Configuration
NAKIVO menyediakan fitur Export System Configuration untuk memindahkan konfigurasi Director ke instance baru. Berdasarkan dokumentasi NAKIVO, konfigurasi yang ikut dipindahkan mencakup inventory, job, credentials, dan Transporter settings.
Pada pengujian ini, konfigurasi berikut berhasil terbawa ke NAKIVO baru:
Inventory Proxmox yang sudah didaftarkan.
Credentials.
Backup job dan replication job.
Schedule dan retention setiap job.
Konfigurasi Transporter.
Referensi atau konfigurasi Backup Repository.
Namun, export system configuration tidak membawa data fisik yang tersimpan di Backup Repository. Artinya, file backup dan recovery point tetap berada di storage server lama dan harus dipindahkan secara terpisah.
Fitur ini juga ditujukan untuk migrasi, bukan sebagai backup konfigurasi rutin. Saat export dilakukan, aktivitas yang sedang berjalan akan dihentikan dan seluruh job pada NAKIVO lama akan dinonaktifkan. Setelah export, sebaiknya jangan menjalankan kembali job pada instance lama jika migrasi akan dilanjutkan ke instance baru.
Sebelum export, saya memastikan tidak ada proses backup, replikasi, recovery, maupun repository maintenance yang sedang berjalan.
Proses export dilakukan melalui menu berikut:
Buka Settings.
Masuk ke General > System Settings.
Pilih tab Configuration.
Klik Export System Configuration.
Pilih Include indexing data jika data indexing juga ingin dipindahkan.
Pilih Encrypt system configuration untuk melindungi credentials di dalam bundle.
Masukkan password, kemudian jalankan export.
Download export bundle setelah proses selesai.
NAKIVO lama kemudian tidak digunakan untuk menjalankan job agar tidak terjadi perbedaan status antara Director lama dan Director baru.
Import Konfigurasi ke NAKIVO Baru
Pada nakivo2, saya memasang NAKIVO Backup & Replication dengan versi dan build yang sama. Import dilakukan melalui:
Buka Settings.
Masuk ke General > System Settings.
Pilih tab Configuration.
Klik Import System Configuration.
Pilih export bundle dari server lama.
Masukkan password bundle.
Klik Import, kemudian Proceed.
Setelah proses selesai, inventory, credentials, backup job, replication job, dan schedule dari NAKIVO lama muncul pada NAKIVO baru. Konfigurasi yang sudah ada sebelumnya pada server baru akan ditimpa oleh konfigurasi dari bundle.
Memindahkan Data Onboard Repository
Walaupun konfigurasi repository sudah terbawa, data backup belum berada pada server baru. Dan masih menunjukkan issue
Lokasi repository pada server lama adalah:
/opt/nakivo/repository/NakivoBackup
Pada server baru, repository saya tempatkan di:
/backup-nakivo/NakivoBackup
Sebelum menyalin data, repository harus dipastikan tidak sedang digunakan oleh job dan sebaiknya di-detach terlebih dahulu. Seluruh folder NakivoBackup kemudian disalin tanpa mengubah atau menghapus file di dalamnya.
Saya memilih menyalin data terlebih dahulu, bukan langsung menghapus repository lama. Dengan demikian, salinan lama masih dapat digunakan sebagai cadangan sampai repository baru berhasil diverifikasi.
Repository hasil import kemudian diedit melalui Settings > Repositories. Assigned Transporter diarahkan ke Onboard Transporter milik nakivo2, sedangkan path diisi dengan:
/backup-nakivo
Path yang dimasukkan adalah direktori induk, bukan /backup-nakivo/NakivoBackup, karena NAKIVO akan mencari folder NakivoBackup di dalam lokasi tersebut.
Jika repository tidak muncul setelah import, repository dapat didaftarkan melalui Settings > Repositories > Add existing backup repository. Pilih Local Folder, tentukan Transporter, lalu masukkan path /backup-nakivo.
Saat menjalankan self-healing, muncul error berikut:
Self-healing of the "Onboard Repository" has failed
Reason: The "Onboard transporter" transporter cannot read and/or
write to the specified location (/backup-nakivo).
Pemeriksaan permission menunjukkan kondisi berikut:
# Server lama
drwxrwxrwx root root /opt/nakivo/repository
drwxrwx--- bhsvc bhsvc /opt/nakivo/repository/NakivoBackup
# Server baru
drwxr-xr-x root root /backup-nakivo
drwxrwx--- bhsvc bhsvc /backup-nakivo/NakivoBackup
Folder NakivoBackup sudah dimiliki oleh bhsvc, tetapi folder induk /backup-nakivo masih dimiliki root:root dengan permission 755. Akibatnya, Onboard Transporter dapat membuka folder tersebut, tetapi tidak memiliki hak tulis pada lokasi yang didaftarkan sebagai repository.
Permission dapat disamakan seperti server lama menggunakan chmod 777, tetapi pilihan yang lebih aman adalah memberikan akses hanya kepada user dan grup service NAKIVO:
Sebelum mengaktifkan kembali seluruh schedule, beberapa pemeriksaan yang perlu dilakukan adalah:
Inventory Proxmox dapat di-refresh.
Onboard Transporter berstatus online.
Repository berstatus attached dan accessible.
Backup VM serta recovery point lama dapat ditampilkan.
Self-healing selesai tanpa error.
Satu file atau VM dapat dipulihkan sebagai pengujian.
Satu backup job dapat dijalankan secara manual.
Satu replication job dapat dijalankan secara manual.
Schedule berjalan dari NAKIVO baru tanpa ada job aktif pada NAKIVO lama.
Kesimpulan
Dari pengujian ini, export dan import system configuration dapat memindahkan konfigurasi utama NAKIVO seperti inventory, credentials, job backup, job replikasi, dan schedule. Namun, proses tersebut tidak memindahkan data fisik pada Onboard Repository.
Data repository tetap harus disalin atau dipindahkan secara manual, kemudian path, Assigned Transporter, ownership, dan permission disesuaikan pada server baru. Hal penting yang saya temukan adalah permission folder NakivoBackup saja belum cukup; user bhsvc juga harus memiliki akses baca dan tulis pada direktori induk yang didaftarkan sebagai lokasi repository.
Saya ditugaskan untuk membuat cluster Proxmox VE yang terdiri dari dua node dan menggunakan Ceph sebagai shared storage. Setelah konfigurasi selesai, kemudian saya ditugaskan untuk melakukan pengujian dengan mematikan salah satu node untuk mengetahui kondisi VM, quorum Proxmox, dan quorum Ceph.
Eksperimen ini juga menguji solusi sementara berupa penghapusan Ceph Monitor pada pveceph2 dan penggunaan pvecm expected 1. Hasilnya menunjukkan bahwa quorum Proxmox/Corosync, quorum Ceph Monitor, dan redundansi data Ceph merupakan tiga hal berbeda yang harus ditangani secara terpisah.
Catatan: Konfigurasi dua node, satu Ceph Monitor, serta pool size 2/min_size 1 pada artikel ini digunakan untuk eksperimen. Konfigurasi tersebut bukan rekomendasi untuk lingkungan produksi.
Lingkungan Pengujian
Komponen
Konfigurasi
Proxmox VE
9.2.10
Kernel
7.0.14-12-pve
Ceph
Squid 19.2.5
Node 1
pveceph1
Node 2
pveceph2
OSD
3 OSD pada setiap node, total 6 OSD
Pool
pvecephpool
Replikasi pool
size 2, min_size 1
VM pengujian
Alpine Linux pada pveceph1 dengan disk di pvecephpool
Pada konfigurasi ini, size 2 membuat Ceph menyimpan dua salinan data. Sementara itu, min_size 1 mengizinkan I/O tetap berjalan ketika hanya tersedia satu salinan. Konfigurasi ini membantu pengujian dua node, tetapi meningkatkan risiko kehilangan data ketika penulisan berlangsung tanpa redundansi. Dokumentasi Proxmox Ceph juga memperingatkan bahwa replicated pool dengan min_size 1 dapat menyebabkan kehilangan data atau PG menjadi tidak lengkap jika salinan terakhir bermasalah.
1. Membuat Cluster Proxmox Dua Node
Pembuatan cluster dapat dilakukan melalui GUI Proxmox.
Membuat cluster pada pveceph1
Login ke GUI pveceph1.
Buka Datacenter → Cluster.
Klik Create Cluster.
Masukkan nama cluster.
Pilih jaringan Corosync yang akan digunakan pada bagian Cluster Network.
Klik Create.
Setelah cluster terbentuk, klik Join Information, lalu salin informasi yang ditampilkan.
Menggabungkan pveceph2
Login ke GUI pveceph2.
Buka Datacenter → Cluster.
Klik Join Cluster.
Tempel informasi dari pveceph1.
Masukkan password root milik pveceph1.
Pastikan alamat jaringan Corosync sudah sesuai.
Klik Join.
Node yang akan bergabung sebaiknya belum memiliki VM atau konfigurasi penting karena konfigurasi cluster pada node tersebut akan disesuaikan dengan cluster tujuan. Langkah GUI ini sesuai dengan panduan Proxmox VE Cluster Manager.
Periksa halaman Datacenter → Cluster setelah proses selesai. Pastikan pveceph1 dan pveceph2 terlihat berstatus online.
2. Menginstal dan Mengonfigurasi Ceph
Menginstal Ceph pada kedua node
Lakukan langkah berikut pada pveceph1 dan pveceph2:
Pilih nama node pada panel kiri.
Buka menu Ceph.
Klik Install Ceph atau ikuti wizard instalasi yang muncul.
Pilih Ceph Squid dan repository yang sesuai.
Selesaikan instalasi paket.
Pada node pertama, lanjutkan dengan inisialisasi konfigurasi Ceph. Tentukan Public Network dan Cluster Network sesuai jaringan yang sudah disiapkan. Node kedua menggunakan konfigurasi Ceph yang sudah tersimpan pada cluster, sehingga tidak perlu membuat cluster Ceph baru.
Periksa halaman konfigurasi Ceph.
Membuat Ceph Monitor
Pada konfigurasi awal eksperimen, MON dibuat pada kedua node:
Buka Ceph → Monitor.
Klik Create.
Pilih pveceph1, kemudian buat MON.
Ulangi untuk pveceph2.
Jika wizard konfigurasi sudah otomatis membuat MON pada pveceph1, cukup buat MON tambahan pada pveceph2.
Dengan dua MON, quorum membutuhkan keduanya aktif atau 2 dari 2 MON. Artinya, konfigurasi ini belum dapat menoleransi kegagalan satu MON. Ceph merekomendasikan sedikitnya tiga MON untuk produksi dan jumlah MON ganjil agar mayoritas tetap dapat terbentuk ketika satu MON gagal.
Periksa halaman Ceph → Monitor yang menampilkan MON pveceph1 dan pveceph2 dalam kondisi aktif serta berada dalam quorum.
Membuat enam OSD (Sesuaikan dengan kebutuhan)
Setiap node pada lab ini memiliki tiga disk khusus OSD.
Pilih node yang akan dikonfigurasi.
Buka Ceph → OSD.
Klik Create: OSD.
Pilih disk kosong yang akan digunakan.
Pastikan disk yang dipilih tidak berisi data penting.
Klik Create.
Ulangi hingga tersedia tiga OSD pada setiap node.
Peringatan: Pembuatan OSD akan menghapus isi disk yang dipilih. Periksa nama dan kapasitas disk sebelum menekan Create.
Periksa halaman Ceph → OSD atau tampilan CRUSH yang menunjukkan enam OSD berstatus up dan in, masing-masing tiga OSD di bawah pveceph1 dan pveceph2.
Membuat pool Ceph
Buka Ceph → Pools.
Klik Create.
Isi nama pool dengan pvecephpool.
Buat pool terlebih dahulu dengan Size3 dan Min. Size2.
Pilih CRUSH rule yang menempatkan replika pada host berbeda.
Aktifkan opsi penambahan storage jika tersedia, lalu klik Create.
Setelah pvecephpool berhasil dibuat, ubah konfigurasinya menjadi size 2/min_size 1:
Pilih pool pvecephpool, lalu klik Edit.
Ubah Size dari 3 menjadi 2.
Ubah Min. Size dari 2 menjadi 1.
Simpan perubahan.
Pilih pool internal .mgr, lalu klik Edit.
Ubah Size dan Min. Size pada .mgr menjadi 2 dan 1.
Simpan perubahan dan tunggu proses penyesuaian PG selesai.
Catatan: Pada eksperimen ini, konfigurasi 2/1 tidak langsung diterapkan ketika membuat pool. Pool dibuat lebih dahulu dengan nilai 3/2, kemudian pvecephpool dan pool internal .mgr diedit menjadi 2/1. Jika hanya pvecephpool yang diubah, .mgr masih menggunakan 3/2 dan Ceph dapat tetap menampilkan peringatan karena cluster hanya memiliki dua host OSD. Pool .mgr tidak perlu dihapus; cukup sesuaikan nilai replikasinya.
Jika pool belum muncul sebagai storage Proxmox, buka Datacenter → Storage → Add → RBD, lalu pilih pvecephpool sebagai pool. Aktifkan jenis konten Disk image sesuai kebutuhan.
3. Membuat VM Pengujian pada Ceph
Klik Create VM.
Tempatkan VM pada pveceph1.
Gunakan ISO Alpine Linux atau sistem operasi ringan lainnya.
Pada bagian disk, pilih pvecephpool sebagai storage.
Selesaikan instalasi, kemudian jalankan VM.
Pastikan status VM Running sebelum pengujian dimulai.
Sebelum mematikan node, pastikan status Ceph normal, kedua MON berada dalam quorum, dan seluruh OSD berstatus up serta in.
Periksa halaman Hardware VM yang menunjukkan disk berada di pvecephpool dan pastikan VM berstatus Running.
4. Pengujian Pertama: Mematikan pveceph2
Node kedua dimatikan langsung melalui GUI:
Pilih pveceph2 pada panel kiri.
Klik Shutdown.
Konfirmasi proses shutdown.
Tunggu hingga pveceph2 benar-benar tidak aktif.
Setelah itu, pemeriksaan dilakukan melalui GUI pveceph1.
Hasil pengujian
VM Alpine pada pveceph1 tetap berstatus Running.
MON pveceph2 tidak aktif sehingga dua MON tidak dapat membentuk mayoritas.
Tiga OSD milik pveceph2 menjadi down dan PG kehilangan satu salinan data.
Cluster Proxmox kehilangan quorum karena hanya tersedia satu dari dua vote Corosync.
Pembuatan VM baru tidak dapat dilakukan karena pmxcfs menjadi read-only ketika cluster Proxmox tidak quorate.
VM yang sudah berjalan dapat tetap aktif karena proses QEMU masih berjalan dan jalur data Ceph tidak selalu langsung berhenti ketika MON tidak memiliki quorum. Namun, kondisi tersebut tidak boleh dianggap sebagai jaminan ketersediaan. Perubahan peta cluster, koneksi baru, atau gangguan tambahan tetap dapat menyebabkan I/O berhenti.
VM tetap running (dapat di ping) namun tidak dapat diakses.
5. Menghapus MON pveceph2
Pengujian berikutnya bertujuan memastikan MON pada node yang mati tidak lagi menjadi bagian dari quorum Ceph. Sebelum menghapus MON, pveceph2 dinyalakan kembali dan ditunggu hingga cluster Proxmox serta Ceph kembali normal.
Jika GUI tidak dapat digunakan, perintah berikut dapat dijalankan melalui menu Shell pada pveceph2 ketika node masih aktif dan quorum tersedia:
pveceph mon destroy pveceph2
Pada eksperimen ini yang dihapus hanya service MON. OSD pada pveceph2 tetap dipertahankan sebagai bagian dari pool.
Mengulangi pengujian shutdown
Setelah MON pveceph2 berhasil dihapus, node tersebut kembali dimatikan melalui GUI. Hasilnya:
VM pada pveceph1 tetap Running.
MON tunggal pveceph1 dapat membentuk quorum 1 dari 1.
Error quorum MON yang sebelumnya terjadi tidak lagi menjadi penghambat.
Ceph tetap menampilkan kondisi degraded atau undersized karena tiga OSD pada pveceph2 tidak tersedia.
Cluster Proxmox tetap tidak quorate karena Corosync masih hanya memiliki satu dari dua vote.
Pembuatan VM atau perubahan konfigurasi tetap terblokir pada sisi Proxmox.
Penghapusan MON kedua hanya mengubah quorum Ceph. Langkah ini tidak memperbaiki quorum Proxmox dan tidak mengembalikan redundansi data Ceph.
Pengujian pembuatan VM gagal
6. Menggunakan pvecm expected 1 untuk Pengujian
Dalam pengujian ini, perintah berikut dijalankan melalui pveceph1 → Shell setelah dipastikan bahwa pveceph2 benar-benar mati:
pvecm expected 1
Perintah tersebut mengubah jumlah vote yang diharapkan menjadi satu sehingga pveceph1 kembali quorate. Setelah itu, pmxcfs dapat ditulis kembali dan pengujian melalui GUI dapat dilanjutkan. Pada lab ini, pembuatan VM baru digunakan hanya untuk membuktikan bahwa hambatan sebelumnya berasal dari quorum Proxmox.
Peringatan:pvecm expected 1 merupakan tindakan pemulihan sementara, bukan konfigurasi permanen untuk cluster dua node. Jalankan hanya setelah node lain dipastikan benar-benar mati atau sudah di-fence. Jangan menjalankannya pada dua sisi yang terpisah karena dapat menyebabkan split-brain dan perubahan konfigurasi yang saling bertentangan. Dokumentasi Proxmox menempatkan perintah ini sebagai workaround ketika quorum hilang dan memperingatkan agar perubahan yang memengaruhi cluster tidak dilakukan dalam kondisi vote dipaksa. Untuk produksi, QDevice direkomendasikan sebagai vote ketiga pada cluster dua node.
Ringkasan Hasil Pengujian
Kondisi
Quorum Proxmox
Quorum Ceph MON
Kondisi data Ceph
VM yang sudah berjalan
Perubahan konfigurasi/VM baru
Kedua node aktif, dua MON
Ada
2/2
Normal
Berjalan
Bisa
pveceph2 mati, dua MON masih terdaftar
Tidak ada
Tidak ada, hanya 1/2
Degraded, satu replika tersisa
Tetap berjalan pada pengujian
Tidak bisa
pveceph2 mati, MON-nya sudah dihapus
Tidak ada
Ada, 1/1
Degraded, satu replika tersisa
Tetap berjalan pada pengujian
Tidak bisa
Kondisi sebelumnya + pvecm expected 1
Ada secara paksa
Ada, 1/1
Tetap degraded
Tetap berjalan pada pengujian
Dapat diuji melalui GUI
Tabel tersebut menunjukkan bahwa MON Ceph dan quorum Corosync bekerja secara independen. Memperbaiki salah satunya tidak otomatis memperbaiki komponen lain.
Solusi Implementasi Dua Node
Menggunakan satu MON memang membuat Ceph memiliki quorum 1/1, tetapi seluruh cluster bergantung pada pveceph1. Jika MON tersebut mati, Ceph tidak memiliki MON lain untuk mengambil alih. Karena itu, konfigurasi ini hanya sesuai untuk membuktikan perilaku sistem dalam lab.
Untuk implementasi dua node yang mempertimbangkan biaya subscription Proxmox, rencana pengujian berikutnya adalah menambahkan satu VM atau server Linux independen. Perannya mirip witness, tetapi komponen yang digunakan berbeda untuk Proxmox dan Ceph.
1. QDevice untuk quorum Proxmox
Pada sisi Proxmox/Corosync, server independen menjalankan corosync-qnetd. Kedua node PVE kemudian menggunakan QDevice untuk memperoleh vote ketiga. Dengan demikian, satu node PVE yang masih aktif bersama QDevice dapat mempertahankan quorum. Proxmox secara resmi merekomendasikan QDevice untuk cluster dua node yang membutuhkan ketersediaan lebih baik pada panduan Proxmox VE Cluster Manager.
2. MON ketiga untuk quorum Ceph
Pada sisi Ceph tidak terdapat QDevice yang sama seperti Corosync. Solusinya adalah menjalankan Ceph Monitor ketiga pada server atau VM independen. Sebelum pengujian ini dilakukan, MON pveceph2 perlu dibuat kembali sehingga susunannya menjadi:
MON pveceph1;
MON pveceph2;
MON ketiga pada host independen.
Dengan tiga MON, Ceph dapat mempertahankan quorum ketika satu MON mati karena masih tersedia dua dari tiga MON. MON ketiga adalah MON penuh yang menyimpan cluster map dan ikut melakukan voting, bukan sekadar QDevice. Prinsip mayoritas dan rekomendasi minimal tiga MON dijelaskan pada dokumentasi Adding/Removing Monitors.
Jika MON ketiga ditempatkan pada VM, disk dan proses boot VM tersebut tidak boleh bergantung pada pvecephpool yang sedang dilindungi. VM harus berjalan pada host, storage, dan jalur daya yang independen agar tidak terjadi ketergantungan melingkar.
Untuk lab atau lingkungan dengan sumber daya terbatas, satu server independen dapat diuji untuk menjalankan corosync-qnetd dan Ceph MON ketiga. Keduanya tetap merupakan service berbeda dan harus diuji secara terpisah. Kompatibilitas versi Ceph, prosedur pemeliharaan, serta dukungan vendor perlu dipastikan sebelum digunakan pada produksi.
3. MON ketiga tidak menambah replika data
Penambahan MON ketiga hanya mempertahankan quorum monitor. Ketika pveceph2 mati, tiga OSD di node tersebut tetap hilang dan pool size 2/min_size 1 hanya dapat melanjutkan I/O dengan satu salinan data jika PG masih aktif. Ceph tetap dapat menampilkan HEALTH_WARN, degraded, atau undersized.
Jika dibutuhkan redundansi storage yang benar-benar dapat menoleransi kegagalan satu host tanpa berjalan pada satu salinan, diperlukan host OSD ketiga atau desain storage lain yang sesuai. Backup eksternal juga tetap wajib karena replikasi Ceph bukan pengganti backup.
Pertimbangan Biaya Subscription
Jika pada lingkungan produksi menggunakan subscription Proxmox, setiap server fisik Proxmox VE harus dicakup sesuai jumlah CPU socket yang digunakan, dan seluruh node dalam satu cluster menggunakan tingkat subscription yang sama. Karena itu, menambahkan node PVE ketiga dapat meningkatkan biaya subscription. Ketentuan ini dapat dilihat pada Proxmox Subscription FAQ.
Alternatif berupa server Linux independen yang hanya menjalankan QDevice dan Ceph MON dapat menghindari penambahan node PVE ketiga. Namun, desain ini menggunakan MON eksternal yang dikelola secara manual.
Rencana Pengujian Berikutnya
Sesuai arahan yang ditugaskan pada saya, pengujian selanjutnya berfokus pada penambahan Ceph MON di luar cluster PVE agar jumlah MON menjadi 3 dan min_size menjadi 2 dan quorum Ceph tetap tersedia ketika salah satu node PVE mati. Host eksternal akan berperan mirip QDevice, tetapi menjalankan Ceph MON penuh.
Topologi yang akan diuji:
Host
Cluster PVE
Service Ceph
pveceph1
Cluster pveceph
MON dan 3 OSD
pveceph2
Cluster pveceph
MON dan 3 OSD
PVE standalone atau Linux lain
Di luar cluster
MON eksternal tanpa OSD
Tahapan pengujiannya adalah sebagai berikut:
Menyiapkan PVE standalone atau server/VM Linux pada infrastruktur dan storage yang independen dari pvecephpool.
Memasang paket Ceph yang kompatibel dengan Ceph Squid 19.2.5 pada host eksternal.
Menyalakan pveceph2 dan membuat kembali MON pada node tersebut.
Menambahkan Ceph MON ketiga pada host eksternal.
Memastikan ketiga MON berstatus aktif dan membentuk quorum 3/2.
Kesimpulan
Pada eksperimen ini, VM di pveceph1 tetap berjalan ketika pveceph2 dimatikan, tetapi pembuatan VM baru terblokir karena cluster Proxmox kehilangan quorum. Menghapus MON pveceph2 membuat MON tunggal pveceph1 memiliki quorum 1/1, sedangkan pvecm expected 1 memungkinkan pengujian lanjutan pada sisi Proxmox.
Kedua tindakan tersebut hanya solusi sementara untuk lab. Desain dua node yang lebih tepat membutuhkan QDevice untuk quorum Proxmox dan MON ketiga pada host independen untuk quorum Ceph. Jika targetnya juga mempertahankan redundansi data ketika satu node mati, MON ketiga saja tidak cukup—dibutuhkan OSD pada host ketiga atau arsitektur storage lain yang sesuai.
Ceph umumnya menggunakan minimal tiga Monitor untuk menyediakan quorum dan redundansi. Namun, pada pengujian ini saya mencoba menjalankan cluster Proxmox VE dua node dengan hanya satu Ceph Monitor.
Tujuan pengujian ini adalah mengetahui kondisi VM dan storage Ceph ketika node kedua dimatikan, serta memastikan apakah VM baru masih dapat dibuat pada node yang tetap aktif.
Konfigurasi Homelab
Pengujian dilakukan menggunakan konfigurasi berikut:
Komponen
Konfigurasi
Proxmox VE
9.2.10
Ceph
19.2.5 Squid
Node pertama
pveceph1 – 192.168.14.57
Node kedua
pveceph2 – 192.168.14.58
Jumlah OSD
6 OSD
OSD pveceph1
osd.3, osd.4, dan osd.5
OSD pveceph2
osd.0, osd.1, dan osd.2
Storage VM
pvecephpool
Pool replica
size=2
Minimum replica
min_size=1
Ceph Monitor
Hanya di pveceph1
VM pengujian
Alpine Linux di pveceph1
Pada kondisi awal, kedua node aktif, enam OSD berstatus up/in, seluruh Placement Group berstatus active+clean, dan Ceph menunjukkan status HEALTH_OK.
Mengubah Ceph Menjadi Satu Monitor
Awalnya Ceph memiliki dua Monitor, yaitu:
pveceph1
pveceph2
Sebelum Monitor kedua dihapus, dilakukan pemeriksaan untuk memastikan bahwa mon.pveceph2 aman dikeluarkan dari monmap. Hasil pemeriksaan menunjukkan:
root@pveceph1:~# ceph mon ok-to-rm pveceph2
safe to remove mon.pveceph2
Monitor pveceph2 kemudian dihapus melalui Proxmox Web GUI dengan langkah berikut:
Pilih node pveceph2.
Buka menu Ceph → Monitor.
Pilih Monitor pveceph2.
Klik Destroy.
Konfirmasi penghapusan dan tunggu sampai proses selesai.
Alternatifnya, penghapusan Monitor dapat dilakukan melalui CLI pada node pveceph2:
pveceph mon destroy pveceph2
Proses tersebut hanya menghapus fungsi Ceph Monitor pada pveceph2. Node Proxmox, tiga OSD, dan layanan Ceph lainnya pada node tersebut tetap dipertahankan.
Setelah proses selesai, Ceph hanya memiliki satu Monitor aktif, yaitu pveceph1, dengan quorum 1/1.
Dokumentasi Ceph menjelaskan:
“A cluster will run fine with a single Monitor; however, a single Monitor is a single-point-of-failure.”
Artinya, satu Monitor tetap dapat melayani cluster Ceph. Namun, jika Monitor tersebut gagal, tidak ada Monitor lain yang dapat mengambil alih. Ceph Monitor Configuration Reference.
Membuat VM Pengujian
Selanjutnya, dibuat satu VM Alpine Linux dengan ketentuan berikut:
VM ditempatkan di node pveceph1.
Disk VM menggunakan storage pvecephpool.
VM tidak dimasukkan ke dalam konfigurasi Proxmox HA.
VM dinyalakan sebelum proses pengujian dimulai.
Melalui Web GUI, VM dipastikan telah berstatus Running dan disk-nya menggunakan storage Ceph.
Mematikan pveceph2
Setelah VM Alpine berjalan, node pveceph2 dimatikan melalui Proxmox Web GUI:
Pilih node pveceph2.
Klik tombol Shutdown.
Konfirmasi proses shutdown.
Tunggu sampai node benar-benar berstatus offline.
Setelah pveceph2 mati, pemeriksaan dilakukan melalui Web GUI pada pveceph1, meliputi:
Status VM Alpine pada halaman Summary.
Status node pada halaman Datacenter.
Status Ceph pada menu Ceph.
Status Monitor pada menu Ceph → Monitor.
Status OSD pada menu Ceph → OSD.
Status storage pvecephpool.
Percobaan membuat VM baru di pveceph1.
Hasil Pengujian
VM yang sudah berjalan tetap running
Setelah pveceph2 dimatikan, VM Alpine di pveceph1 tetap berstatus Running.
Hal ini terjadi karena:
Ceph Monitor pveceph1 tetap memiliki quorum 1/1.
Tiga OSD di pveceph1 masih aktif.
Pool menggunakan min_size=1.
Proses VM telah berjalan di pveceph1.
Meskipun VM tetap berjalan, Ceph berada dalam kondisi degraded karena tiga OSD pada pveceph2 sudah tidak tersedia.
Dengan size=2 dan min_size=1, Ceph masih dapat melayani I/O menggunakan satu replica yang tersedia. Namun, data pada kondisi tersebut hanya memiliki satu salinan aktif.
Dokumentasi Ceph memperingatkan bahwa penggunaan size=2 atau min_size=1 memiliki risiko kehilangan data dan tidak direkomendasikan sebagai konfigurasi normal untuk production. Dokumentasi Ceph Pool.
VM baru tidak dapat dibuat
Ketika dilakukan percobaan membuat VM baru di pveceph1, proses tersebut gagal walaupun storage Ceph masih dapat diakses.
Kegagalan ini bukan disebabkan oleh single Ceph Monitor, melainkan karena cluster Proxmox kehilangan quorum.
Cluster Proxmox masih mengharapkan dua vote, sedangkan setelah pveceph2 dimatikan hanya tersedia satu vote dari pveceph1. Akibatnya, Proxmox Cluster File System atau pmxcfs berubah menjadi read-only.
Dokumentasi Proxmox menjelaskan salah satu karakteristik pmxcfs sebagai berikut:
“Read-only when a node loses quorum.”
Karena konfigurasi VM disimpan di dalam /etc/pve, Proxmox tidak dapat menulis konfigurasi VM baru ketika cluster tidak memiliki quorum. Dokumentasi Proxmox pmxcfs.
Ringkasan Hasil
Pengujian
Hasil
Ceph Monitor pveceph2 dihapus
Berhasil
Ceph berjalan dengan satu Monitor
Berhasil, quorum 1/1
pveceph2 dimatikan
Berhasil
VM Alpine di pveceph1
Tetap running
Storage Ceph
Tetap tersedia, tetapi degraded
OSD pada pveceph2
Down
Membuat VM baru di pveceph1
Gagal
Penyebab kegagalan
PVE/Corosync kehilangan quorum
Pengujian Lanjutan
Untuk kebutuhan lab, jumlah expected vote dapat diubah sementara menjadi satu:
pvecm expected 1
Perintah tersebut dapat membuat pveceph1 kembali memiliki quorum sehingga pengujian pembuatan VM baru dapat dilanjutkan.
Namun, perintah ini hanya boleh digunakan setelah memastikan pveceph2 benar-benar mati, bukan sekadar terputus dari jaringan. Penggunaannya dalam kondisi node lain masih aktif dapat menimbulkan risiko split-brain.
Untuk cluster Proxmox dua node yang digunakan secara permanen, Proxmox merekomendasikan QDevice sebagai vote ketiga. Dokumentasi Proxmox Cluster Manager.
Kesimpulan
Pengujian menunjukkan bahwa satu Ceph Monitor di pveceph1 tetap dapat melayani storage ketika pveceph2 dimatikan. VM Alpine yang sudah berjalan tetap berstatus Running karena Ceph masih memiliki MON quorum 1/1 dan pool memperbolehkan I/O dengan satu replica.
Namun, VM baru tidak dapat dibuat karena cluster Proxmox kehilangan quorum dan pmxcfs berubah menjadi read-only. Dengan demikian, kegagalan pembuatan VM baru berasal dari quorum PVE/Corosync, bukan dari quorum Ceph.
Konfigurasi satu Ceph Monitor dan pool size=2/min_size=1 dapat digunakan untuk eksperimen, tetapi tidak direkomendasikan untuk production karena tidak memiliki redundansi Monitor dan hanya menyisakan satu salinan data ketika salah satu node mati.
Email menjadi bagian penting dalam komunikasi, pertukaran dokumen, dan transaksi perusahaan. Pelaku kejahatan tidak hanya menyerang mail server, tetapi juga memanfaatkan kepercayaan terhadap nama pengirim, domain, dan percakapan yang terlihat sah.
Serangan perlu dibedakan menjadi dua area. Pertama, serangan terhadap infrastruktur, seperti eksploitasi server yang belum di-patch, penyalahgunaan SMTP Relay, akun administrator, atau DNS. Kedua, penipuan melalui akun dan pesan, seperti phishing, spoofing, pengambilalihan akun, dan manipulasi transaksi. Jenis kedua dapat terjadi tanpa membobol mail server.
Jenis Ancaman pada Email
1. Phishing dan Spear Phishing
Pelaku mengarahkan korban ke halaman login, tautan, atau lampiran berbahaya. Spear phishing disesuaikan dengan jabatan atau aktivitas korban. Indikasinya antara lain permintaan mendesak, URL tidak sesuai, dan login dari perangkat asing. Dampaknya berupa pencurian kredensial dan akses awal ke sistem. Cegah dengan MFA, penyaringan konten, dan edukasi pengguna. CISA menjelaskan cara kerja dan mitigasi phishing.
2. Business Email Compromise
Dalam Business Email Compromise (BEC), pelaku menyamar sebagai pimpinan, vendor, atau bagian keuangan untuk meminta pembayaran, data, atau perubahan rekening. Periksa instruksi mendadak, domain yang hampir sama, Reply-To berbeda, dan permintaan melewati prosedur. Dampaknya berupa kerugian finansial atau kebocoran informasi. Perubahan pembayaran harus diverifikasi melalui kanal lain. FBI menyebut BEC sebagai pesan yang seolah-olah berasal dari sumber dikenal.
3. Email Spoofing dan Domain Impersonation
Pelaku memalsukan pengirim atau menggunakan domain menyerupai domain resmi. Periksa header, Authentication-Results, SPF, DKIM, DMARC, dan karakter domain. Ketiga mekanisme tersebut mengurangi pemalsuan domain, tetapi tidak menjamin identitas individu atau menghentikan domain tiruan. NIST merekomendasikannya untuk meningkatkan kepercayaan terhadap email.
4. Account Takeover
Account takeover terjadi ketika pelaku memperoleh password, token, atau sesi melalui phishing, penggunaan ulang password, malware, atau kebocoran data. Indikasinya berupa login dari IP, lokasi, perangkat, atau waktu yang tidak biasa dan email yang tidak dibuat pengguna. Dampaknya mencakup akses ke mailbox, kontak, dan layanan lain. Gunakan password unik, MFA, pembatasan sesi, dan nonaktifkan autentikasi lama. IC3 menjelaskan metode pengambilalihan akun dan pentingnya MFA.
5. Manipulasi Percakapan Email
Setelah menguasai akun, pelaku dapat memantau dan masuk ke dalam thread transaksi. Perubahan gaya bahasa, Reply-To, dokumen, rekening, atau waktu pengiriman menjadi indikasi. Karena pesan berasal dari akun sah, autentikasi domain dapat tetap lolos. Verifikasi perubahan data penting melalui kanal resmi yang sudah dikenal.
6. Forwarding Rule Tanpa Izin
Pelaku dapat membuat aturan untuk meneruskan, memindahkan, atau menghapus email sehingga transaksi terpantau dan notifikasi keamanan tersembunyi. Periksa seluruh inbox rule, penerusan eksternal, folder tidak umum, dan log perubahan. Batasi penerusan keluar serta buat peringatan perubahan aturan. Microsoft mendokumentasikan pola penyalahgunaan ini.
7. Penyalahgunaan Open Relay atau Akun SMTP
Open relay, cakupan trusted network terlalu luas, atau kredensial SMTP yang bocor dapat digunakan untuk mengirim spam, phishing, dan malware. Gejalanya berupa lonjakan email keluar, mail queue, keluhan penerima, atau IP masuk blacklist. Dampaknya adalah pemblokiran pengiriman dan penurunan reputasi. Batasi relay, wajibkan autentikasi, terapkan rate limit, dan pantau volume.
8. Malware dan Ransomware
Lampiran atau tautan berbahaya dapat menjalankan malware pada perangkat korban. Indikasinya berupa deteksi antivirus atau EDR, proses tidak biasa, koneksi mencurigakan, serta file terenkripsi. Dampaknya mencakup pencurian data dan gangguan operasional. Terapkan pemindaian, sandboxing, pemblokiran ekstensi berisiko, patch rutin, backup teruji, dan pelatihan pengguna.
9. Pencurian dan Kebocoran Data
Email, lampiran, dan kontak dapat disalin melalui forwarding, sinkronisasi IMAP, ekspor, atau pengiriman keluar. Indikasinya berupa akses massal, lampiran besar, penerima tidak biasa, dan aktivitas di luar jam kerja. Terapkan pembatasan akses, DLP, audit mailbox, dan retensi log. Pada Microsoft 365, audit MailItemsAccessed dapat membantu menentukan cakupan email yang diakses. Dokumentasi Microsoft menjelaskan penggunaannya.
Pemeriksaan oleh Administrator Email
Pemeriksaan sebaiknya dilakukan pada beberapa lapisan berikut:
Identitas: log autentikasi, percobaan login, IP, lokasi, perangkat, perubahan password, sesi aktif, metode MFA, dan aplikasi yang diberi akses.
Mailbox: forwarding rule, filter, delegasi, folder Sent dan Deleted, serta perubahan signature atau profil pengguna.
Alur email: lonjakan pengiriman, mail queue, log SMTP, message trace, alamat tujuan, dan pola gagal-kirim.
Administrasi: perubahan hak akses dan konfigurasi, aktivitas administrator, serta log yang hilang, terputus, atau berubah secara tidak wajar.
Gunakan pengamanan berlapis: MFA, password policy, pembatasan hak akses, penonaktifan protokol lama, dan evaluasi sesi. Pada server, lakukan patch rutin, nonaktifkan open relay, batasi trusted network, terapkan SMTP Authentication dan rate limit, serta pantau mail queue. Lengkapi DNS dan transport dengan SPF, DKIM, DMARC, TLS, MTA-STS, dan TLS-RPT. Backup konfigurasi dan data, kirim log ke lokasi terpisah, tetapkan retensi yang cukup, dan lakukan monitoring. Untuk transaksi, setiap perubahan rekening wajib diverifikasi melalui kanal lain dan sebaiknya menggunakan persetujuan dua pihak.
Penanganan Awal Insiden
Jika ditemukan indikasi insiden, lakukan tindakan berikut:
Isolasi atau nonaktifkan sementara akun yang terdampak.
Reset password dan cabut seluruh sesi serta token aktif.
Periksa forwarding rule, delegasi, metode MFA, dan perubahan konfigurasi.
Simpan log, header email, dan bukti transaksi sebelum melakukan pembersihan.
Blokir IP, domain, alamat pengirim, dan indikator serangan yang terverifikasi.
Hubungi bank secepatnya apabila berkaitan dengan transaksi keuangan.
Informasikan insiden kepada manajemen, pemilik data, tim legal, dan pihak berwenang sesuai kebutuhan.
Tentukan cakupan dampak, pulihkan layanan, lalu perbaiki kontrol yang gagal.
Keamanan email tidak cukup hanya mengandalkan antispam. Perlindungan harus mencakup server, akun, DNS, koneksi antarmail server, log, prosedur transaksi, dan kesadaran pengguna. Kombinasi kontrol teknis dan verifikasi manusia menjadi kunci untuk mencegah email digunakan sebagai sarana pencurian, kecurangan, dan penipuan.
Windows dapat berjalan dengan baik di Proxmox, tetapi ada beberapa konfigurasi yang sebaiknya disiapkan sebelum instalasi. Kesalahan yang paling umum adalah disk tidak terdeteksi, network adapter tidak muncul, atau Windows 11 gagal karena TPM dan Secure Boot belum tersedia.
Berikut beberapa tips agar proses instalasi lebih lancar dan performa VM tetap optimal.
Persiapan
Siapkan dua file ISO berikut:
ISO Windows dari sumber resmi Microsoft.
ISO driver VirtIO versi stable.
ISO Windows digunakan untuk instalasi sistem operasi, sedangkan ISO VirtIO berisi driver disk, network adapter, ballooning, dan QEMU Guest Agent. Proxmox juga merekomendasikan VirtIO karena memberikan performa lebih baik dibandingkan perangkat yang diemulasikan.
Sebagai titik awal, resource VM dapat disesuaikan seperti berikut:
Kebutuhan
CPU
RAM
Disk
Testing ringan
2–4 vCPU
4–8 GB
64 GB
Penggunaan harian
4 vCPU
8–16 GB
80 GB atau lebih
Windows Server
Sesuai aplikasi
Minimal 8 GB
Sesuai kebutuhan data
Angka tersebut merupakan rekomendasi praktis, bukan batas tetap. Sesuaikan kembali dengan aplikasi yang akan dijalankan dan kapasitas host Proxmox.
1. Gunakan UEFI dan TPM untuk Windows 11
Saat membuat VM Windows 11, gunakan konfigurasi berikut pada bagian System:
Machine: q35
BIOS: OVMF (UEFI)
Tambahkan EFI Disk
Aktifkan Pre-Enroll Keys untuk Secure Boot
Tambahkan TPM State versi 2.0
Microsoft mensyaratkan UEFI dan TPM 2.0 untuk Windows 11. Menyiapkan keduanya sejak awal juga lebih aman daripada melakukan bypass pemeriksaan hardware ketika instalasi.
2. Pasang Dua ISO Sejak Awal
Pada hardware VM, pasang:
ISO Windows sebagai CD/DVD pertama.
ISO VirtIO sebagai CD/DVD kedua.
Jangan menunggu sampai Windows selesai dipasang. Driver storage dari ISO VirtIO diperlukan ketika Windows Installer belum dapat melihat virtual disk.
3. Gunakan VirtIO SCSI untuk Disk
Gunakan VirtIO SCSI single sebagai SCSI Controller, kemudian pasang disk utama menggunakan bus SCSI. Jika storage mendukungnya, aktifkan juga:
Discard untuk membantu pengembalian ruang kosong melalui TRIM.
IO Thread untuk meningkatkan performa I/O.
Ketika halaman pemilihan disk Windows tidak menampilkan storage, klik Load driver, lalu buka ISO VirtIO dan pilih:
vioscsi\w11\amd64
Untuk Windows Server, pilih folder sesuai versinya, misalnya vioscsi\2k22\amd64. Setelah driver dimuat, disk SCSI akan muncul dan instalasi dapat dilanjutkan.
4. Gunakan Network Adapter VirtIO
Pilih model network adapter VirtIO (paravirtualized) agar throughput lebih baik dan penggunaan CPU lebih rendah. Jika network adapter belum terdeteksi di Windows, instal driver dari folder berikut:
NetKVM\w11\amd64
Setelah berhasil masuk ke desktop, jalankan installer guest tools dari ISO VirtIO. Installer tersebut membantu memasang driver VirtIO lain yang masih dibutuhkan. Periksa Device Manager dan pastikan tidak ada perangkat dengan tanda peringatan.
5. Instal dan Aktifkan QEMU Guest Agent
Aktifkan opsi QEMU Guest Agent pada konfigurasi VM Proxmox, kemudian instal servicenya di Windows melalui ISO VirtIO. Pastikan service QEMU Guest Agent berstatus running.
Guest Agent membantu Proxmox membaca informasi VM, menjalankan shutdown dengan lebih baik, serta melakukan freeze dan thaw filesystem ketika proses backup. Hal ini membantu meningkatkan konsistensi backup Windows.
6. Sesuaikan CPU dengan Environment
Untuk homelab atau VM yang hanya berjalan pada satu host, CPU type host dapat digunakan agar fitur CPU fisik diteruskan ke VM dan performanya lebih optimal.
Jika VM akan dipindahkan melalui live migration dalam cluster, gunakan CPU model yang kompatibel dengan seluruh node. CPU type host dapat menyulitkan migrasi apabila spesifikasi prosesor antarnode berbeda.
Kesimpulan
Kunci instalasi Windows di Proxmox adalah menyiapkan virtual hardware dan driver sebelum proses instalasi dimulai. Gunakan OVMF, EFI Disk, dan TPM 2.0 untuk Windows 11, lalu gunakan VirtIO SCSI, VirtIO Network, serta QEMU Guest Agent agar VM dapat berjalan lebih stabil dan efisien.
Dengan konfigurasi tersebut, masalah seperti disk tidak terdeteksi, network adapter hilang, atau status guest agent tidak terbaca dapat dihindari sejak awal.
