Il problema
Chi vende VPS e vuole cambiare pannello ha sempre lo stesso ostacolo: i clienti. Una VM ricreata da zero ha un IP nuovo, un MAC nuovo, a volte un disco da ricopiare a mano. Vuol dire DNS da aggiornare, licenze legate al MAC da rifare, finestre di manutenzione notturne e ticket.
KoaVM parte da un'idea semplice: la VM non si ricrea, si sposta. Stesso disco, stesso IP, stesso MAC, con il minimo fermo possibile.
I passaggi, uno per uno
1. Lettura della sorgente. Il pannello entra via SSH nel nodo di origine con la sua chiave e legge la definizione della VM (per SolusVM 2 e libvirt il dominio libvirt, per Proxmox la configurazione della VM): dischi, formato (qcow2, raw, LVM), bus, firmware (BIOS o UEFI), MAC e IP. Con l'API del vecchio pannello aggiunge nome host e cliente.
2. Controlli. Prima di toccare qualcosa verifica spazio sul pool di destinazione, raggiungibilità del nodo, che l'IP possa arrivare sul nodo nuovo e che il MAC non sia già usato da un'altra istanza. Se un controllo fallisce, la VM non parte.
3. Copia a specchio con la VM accesa. KoaVM prepara sul nodo KoaVM una VM vuota con dischi della stessa dimensione e li espone con qemu-nbd attraverso un tunnel SSH. Poi, sul nodo di origine, avvia una copia a specchio verso quei dischi: con libvirt (anche SolusVM 2) è virsh blockcopy, con Proxmox è drive-mirror via QMP (con un job-id, perché su Proxmox 9 il vecchio comando dal monitor HMP non funziona più). I blocchi passano sul nodo nuovo mentre la VM continua a lavorare, e ogni nuova scrittura viene riportata anche sulla copia.
4. Il momento del passaggio. Quando la copia è allineata, la VM di origine si spegne, la copia si chiude, KoaVM fissa il nome della scheda di rete e accende la VM su KoaVM con lo stesso MAC e lo stesso IP. Questo è il fermo che vede il cliente: nelle nostre prove fra 8,8 e 15,8 secondi, su nodi di laboratorio annidati.
5. Pulizia. Con l'API del vecchio pannello la VM di origine viene sospesa lì, così nessuno la riaccende per errore. Se l'IP è di un fornitore (OVHcloud, Hetzner), KoaVM lo ha già spostato sul server del nodo nuovo.
6. Se qualcosa va storto in qualunque punto, il pannello ferma tutto, riaccende la VM di origine com'era e, se aveva spostato l'IP del fornitore, lo riporta indietro.
Come sappiamo che non si perde niente
Ogni VM del laboratorio ha un piccolo programma che scrive un contatore su disco ogni 0,2 secondi, con fsync. Dopo lo spostamento il contatore deve essere continuo: se mancasse un numero, avremmo perso una scrittura. In tutte le prove è rimasto continuo, e i dischi secondari avevano lo stesso checksum dell'origine.
| VM | Da | Fermo | Sonda HTTP |
|---|---|---|---|
| vps-a | KVM/libvirt | 8,8 s | 9,2 s |
| pve-web3 | Proxmox VE, LVM | 13,2 s | 10,7 s |
| pve-web1 | Proxmox VE, 2 dischi | 13,8 s | 10,4 s |
| solus-web1 | SolusVM 2 | 15,8 s | 14,9 s |
La «sonda HTTP» è il tempo in cui il sito della VM non rispondeva, misurato da fuori.
E se non si può fare a caldo
Alcune VM si spostano meglio a freddo: Windows, VM con dischi molto grandi e poche risorse libere, o quando preferisci una finestra di manutenzione. La VM si spegne, il disco si copia, la VM riparte su KoaVM: il fermo è pari alla copia (nelle prove fra 28 e 45 secondi per dischi di 8–10 GB). Si può pianificare a un'ora precisa, e i clienti ricevono un'email prima e dopo.
Provarlo
La prova gratuita di KoaVM comprende 1 nodo e 5 VPS, migrazione inclusa. Parti dalla guida alla migrazione e iscriviti alla lista d'attesa.