Da vSphere a Proxmox: che cosa migra davvero

Ogni guida per lasciare VMware comincia dal disco, perché il disco è la parte che ha un file. Converta il VMDK, lo importi, lo avvii, fatto.

Il disco è la parte facile. Ciò che fa funzionare una macchina vSphere si trova in altri quattro posti, nessuno dei quali dentro il VMDK: come la piattaforma identifica la macchina, come il guest viene configurato al primo avvio, per quale hardware virtuale il guest ha i driver, e quale agente dentro il guest risponde alle domande su di esso. Ciascuno è un problema diverso su Proxmox, e solo uno di essi si annuncia quando va storto.

Questo è ciò che abbiamo trovato costruendo percorsi di lettura e scrittura contro entrambi, misurato su vCenter 6.7.0 build-24323669.

Il disco, e l’unica chiamata che non c’è

I dischi virtuali in gioco hanno due forme. Una VM vSphere in esecuzione ha un VMDK flat più un piccolo descrittore. Un OVA o un’immagine cloud scaricata ha un VMDK stream-optimized: compresso, sequenziale e non avviabile così com’è.

Il percorso di conversione ovvio è CopyVirtualDisk_Task con una destination spec che nomina il formato di destinazione. Quella chiamata esiste su un host ESXi autonomo e non esiste su vCenter: risponde «The requested operation is not implemented by the server». È un buon esempio di una trappola più generale di questa API, in cui la stessa operazione esiste a un livello di gestione e non a un altro.

Due cose invece funzionano, e vale la pena conoscerle in quest’ordine:

• CopyVirtualDisk_Task senza destination spec funziona su vCenter 6.7 e copia un disco preservandone il tipo. Su questo vCenter richiede l’argomento datacenter; la forma con il solo percorso del datastore viene rifiutata.
• Il percorso di import OVF (CreateImportSpec → ImportVApp → HttpNfcLease → HTTP POST → HttpNfcLeaseComplete) accetta un disco stream-optimized e lo converte strada facendo. Gli serve solo il descrittore .ovf, non l’intero OVA: un OVA è un archivio tar con il descrittore in testa, recuperabile con una singola range request da 128 kB.

Dal lato Proxmox l’equivalente è qm disk import, che prende un VMDK e lo scrive nello storage di destinazione, nel formato proprio di quello storage. Quella parte è davvero semplice.

Il provisioning è modellato in modo diverso sui due lati. vSphere ha due flag, thinProvisioned e eagerlyScrub, e non sono una scelta a tre vie: thin esclude eager, quindi gli stati validi sono thin, thick lazy zeroed e thick eager zeroed. Qualsiasi cosa che lo modelli come un unico enum a quattro valori prima o poi invierà una combinazione impossibile.

Identità: l’ID che ha non è un’identità

Questa morde mesi dopo, non il giorno della migrazione.

Un oggetto vSphere viene indirizzato da un managed object reference, qualcosa come vm-101. Sembra un ID e non lo è: è una chiave nel database di quel particolare vCenter. Ricostruisca o ripristini quel database e il riferimento non segue la macchina, e viene riassegnato a una VM diversa. Ciò che aveva memorizzato sei mesi fa ora punta alla macchina di qualcun altro, e l’operazione che stava per eseguire è uno spegnimento.

L’identificatore duraturo è config.instanceUuid. Memorizzi quello, e risolva il riferimento a ogni operazione tramite FindByUuid.

Proxmox ha la forma opposta. Una VM è un vmid: stabile, leggibile da una persona, visibile in ogni comando, unico per cluster. È più comodo da usare, e ha una conseguenza tutta sua per una migrazione. Sta scegliendo nuove identità, quindi ogni sistema esterno che si riferiva a una macchina con il suo identificatore vSphere va ripuntato.

Anche il modello di collocazione è diverso. Con DRS attivo, l’host su cui gira una VM cambia senza che nessuno lo chieda, quindi a un clone si assegna un resource pool e vSphere sceglie. Su Proxmox l’unità è il nodo e lo spostamento tra nodi è esplicito. Un inventario che registrava «quale host» per un cluster DRS registrava qualcosa che cambia da sé.

La personalizzazione del guest è un altro meccanismo

Entrambe le piattaforme sanno configurare un guest al primo avvio. Lo fanno in modi che non condividono una riga di codice.

Su vSphere, la strada che funziona senza dipendere dal guest è guestinfo: quattro chiavi in extraConfig, lette dal datasource VMware di cloud-init.

Le chiavi .encoding non sono facoltative. Le ometta e cloud-init legge il testo base64 come se fosse il contenuto stesso, e la macchina si presenta con un hostname di quaranta caratteri di sciocchezze. Nessun errore, solo una risposta sbagliata.

L’alternativa, il CustomizeVM_Task di VMware, ha bisogno di VMware Tools nel guest e, su template Linux più vecchi, di un perl funzionante, che è il tipo di requisito che si scopre quando un provisioning si blocca a metà.

Su Proxmox la personalizzazione è un drive cloud-init collegato alla VM, configurato con un piccolo insieme di chiavi: da ipconfig0 a ipconfig3, nameserver, searchdomain, ciuser, cipassword, sshkeys, citype, ciupgrade.

Una di queste ha una trappola che resta invisibile finché non si lamenta un cliente. ciupgrade ha default = 1 nello schema di Proxmox, quindi ometterlo non significa «non aggiornare i pacchetti al primo avvio»; significa «aggiorna». Una casella non spuntata va inviata come un esplicito ciupgrade=0, altrimenti la casella mente. Inoltre non esiste prima di PVE 8.1, dove inviarlo è un errore netto e non una chiave ignorata.

Altre due cose vanno storte allo stesso modo su entrambi i lati. L’instance ID deve cambiare quando una macchina riceve una nuova identità: l’iid-local01 della maggior parte degli esempi significa che una macchina clonata conserva la configurazione del template. E l’interfaccia non avrà il nome che si aspetta: ens160 su VMware, qualcos’altro su KVM. È Netplan con match: {name: "e*"}, anziché un nome di dispositivo indovinato, a far funzionare la stessa immagine su entrambi.

Hardware virtuale per cui il guest ha i driver

vmxnet3 è la scheda di rete predefinita sensata su VMware, e ha una precondizione: ha bisogno di VMware Tools nel guest. Installi un template senza Tools, gli dia una scheda vmxnet3, e il sistema operativo non vede alcuna scheda di rete.

Questo conta due volte. Prima, perché un template che si avvia bene su ESXi può aver bisogno di e1000e al suo posto. E dopo, perché la scelta ad alte prestazioni di Proxmox è virtio, che ha bisogno dei propri driver: presenti nel Linux moderno, assolutamente no in un’immagine Windows di serie. e1000 è l’opzione lenta, noiosa e che funziona ovunque su entrambe le piattaforme, ed è il primo avvio giusto per una macchina in migrazione.

Il controller del disco ha un problema della stessa forma: su Proxmox la strada veloce è virtio-scsi, che di nuovo è una questione di driver. Non abbiamo misurato che cosa comporti cambiare tipo di controller su un guest già installato, ed è una causa frequente di una macchina che migra pulita e poi non si avvia.

L’agente dentro il guest cambia nome

Una quantità sorprendente di ciò che un pannello mostra non viene affatto dall’hypervisor.

Su vSphere, guest.ipAddress viene da VMware Tools. Ne viene anche l’uso reale del disco, tramite guest.disk: il valore summary.storage.committed a livello di datastore è la cifra del provisioning e per un disco thin è fuorviante. Tools non in esecuzione significa che quei campi sono vuoti, e vuoto significa «non lo so», mai «la macchina non ha indirizzo».

Dopo lo spostamento la stessa informazione viene da qemu-guest-agent, un pacchetto diverso con un nome diverso, che va installato. Una flotta che migra senza di esso sembra, nel suo stesso inventario, una flotta che ha perso gli indirizzi.

Un’ulteriore cautela su quell’indirizzo: arriva attraverso il canale proprio dell’hypervisor verso il guest, non attraverso la rete. Può essere perfettamente accurato per una macchina la cui scheda non è collegata a nulla. L’unica cosa che dimostra la raggiungibilità è raggiungerla.

La rete, e la connessione che in silenzio non c’è

vSphere ha due tipi di backing di rete e non si somigliano. Una Network standard è referenziata per nome; un DistributedVirtualPortgroup tramite l’UUID del proprio switch più la chiave del port group.

Costruisca solo la prima forma e, in qualsiasi ambiente con uno switch distribuito, otterrà una scheda collegata a nulla. vCenter non la rifiuta, perché il nome esiste davvero come oggetto di rete. La macchina si avvia senza connettività e l’errore è dentro il guest.

Proxmox è più semplice: una NIC nomina un bridge, con un tag VLAN facoltativo. La corrispondenza spetta a Lei; non c’è alcuna traduzione automatica da un port group a un bridge. Altre due cose da decidere prima del primo spostamento:

• Gli indirizzi MAC. Portarli con sé mantiene valide le prenotazioni DHCP e i vincoli di licenza, e significa che due macchine condividono un MAC se la sorgente viene mai riaccesa. Scelga in modo esplicito.
• Il firewall per VM. vSphere non ne ha uno; quello è NSX, un prodotto separato. Proxmox invece sì. Le macchine che arrivano da VMware non hanno mai avuto un firewall a livello di hypervisor, e accenderne uno è un progetto, non una casella da spuntare.

Ciò che non viaggia, e non è in nessun file

Alcune cose non hanno un corrispondente, e un piano che non le nomina le scopre una alla volta:

• Gli snapshot. La macchina passa come disco flat; un albero di snapshot è una struttura vSphere e non c’è nulla in cui importarlo.
• Il changed block tracking, e con esso qualunque storico di backup incrementale che vi si appoggiava.
• Tag, attributi personalizzati e cartelle. Vivono nel database di vCenter, non sulla macchina.
• Resource pool, regole DRS, riserve e share. Proxmox non ha uno scheduler equivalente, quindi una politica di collocazione scritta come regole DRS diventa una decisione su quale nodo ospita una macchina.
• La VM hardware version. Un concetto vSphere senza corrispondente in Proxmox, quindi qualunque cosa vi si basi nella sua automazione è ora codice morto.

Che cosa fa, e non fa, il nostro strumento

Per essere chiari: non abbiamo costruito la migrazione da vSphere a Proxmox. I nostri strumenti di migrazione oggi coprono esattamente un percorso, tra due pannelli di gioco, e stanno dietro un feature flag disattivato.

Due regole nate costruendo quell’unico percorso vale comunque la pena rubarle, perché rendono una migrazione verificabile anziché speranzosa. La sorgente è in sola lettura, come costante e non come flag, quindi non esiste configurazione in cui lo strumento scriva sul sistema che sta lasciando. E una prova a vuoto è obbligatoria prima di un apply, con un conteggio per categoria alla fine, sorgente contro destinazione. Una migrazione che non sa dirle quante macchine ha spostato non è finita; si è fermata.

Questo testo nasce dalla costruzione delle integrazioni vSphere e Proxmox per Provibr, un pannello di gestione server per hosting provider, dove entrambi gli hypervisor devono essere leggibili attraverso una sola interfaccia senza che nessuno dei due venga descritto come l’altro. Le note di configurazione sono nella documentazione vSphere e Proxmox.