Migrazione · VMware
Migra le macchine virtuali VMware su Apache CloudStack
Apache CloudStack può importare macchine virtuali da VMware vCenter e, a partire dalla versione 4.19, convertirle in KVM. Per farlo in sicurezza servono comunque un inventario, una zona di destinazione, un test preliminare e un piano di cutover per ciascuna macchina. Nei 30 giorni lavorativi inclusi in NexCMP Source, un tecnico esperto segue questo lavoro insieme a te senza costi aggiuntivi.
Incluso con NexCMP Source ($499 una tantum), non con NexCMP Free. VMware, WHMCS, HostBill, Blesta, Paymenter, StackBill, Virtualizor e Apache CloudStack sono marchi registrati dei rispettivi proprietari. NexCMP è indipendente e non è affiliato né approvato da essi.
Il problema: abbandonare VMware senza perdere il controllo
Passare ad Apache CloudStack significa cambiare la piattaforma di ogni macchina virtuale: dischi, schede di rete, driver e spesso indirizzi. Se fatto di fretta, è qui che le macchine non si avviano, i clienti perdono l'accesso o le licenze smettono di funzionare.
CloudStack fornisce gli strumenti di importazione, ma non decide al posto tuo quali macchine migrare per prime, come mappare ciascuna rete, cosa accade ai guest Windows o per quanto tempo ogni macchina rimarrà offline. Queste decisioni, insieme ai relativi test, costituiscono la vera migrazione.
Se rivendi le macchine virtuali ai clienti, la migrazione ha una seconda parte: le macchine devono essere associate ai clienti, ai piani e ai prezzi corretti nel tuo sistema di fatturazione. NexCMP è il layer di fatturazione e portale clienti su CloudStack, e lo stesso sistemista gestisce entrambe le fasi.
Cosa supporta CloudStack nativamente
Esistono due percorsi documentati da VMware. La scelta dipende dal fatto che gli host VMware rimangano o meno nel tuo cloud.
A. Conversione a KVM con virt-v2v
- Cosa documenta CloudStack
- Dalla versione 4.19 un amministratore può selezionare una VM VMware in un datacenter vCenter esistente o esterno e importarla in un cluster KVM, da Tools, Import-Export Instances. La VM viene esportata, convertita con virt-v2v e i suoi dischi vengono importati come QCOW2. La documentazione più recente aggiunge un percorso di streaming basato su VDDK accanto a quello basato su OVF; la versione 4.22 ha introdotto la conversione diretta su uno storage pool e la versione 4.22.1 la selezione del guest OS in base al guest OS di origine.
- Limiti indicati nella documentazione
- virt-v2v non viene installato dall'agent CloudStack e deve essere installato su ogni host KVM, altrimenti la conversione fallisce. Il successo non è garantito e dipende dal guest OS e dai file system; pertanto la documentazione raccomanda di effettuare dei test prima dell'uso in produzione. Nella versione 4.19 la VM importata riceve il tipo di guest OS predefinito CentOS 4.5 (32-bit) e deve essere modificata successivamente.
Source: Apache CloudStack — Importazione di VM VMware in KVM · consultato il 2026-10-19
B. Importazione in loco (unmanaged instances)
- Cosa documenta CloudStack
- Per i cluster vSphere i cui host fanno già parte di CloudStack, listUnmanagedInstances elenca le VM e importUnmanagedInstance le porta sotto la gestione di CloudStack. L'elenco delle istanze VMware non gestite è stato introdotto nella versione 4.14, la rimozione dalla gestione nella 4.15 e l'importazione da UI nella 4.16.
- Limiti indicati nella documentazione
- La rete di destinazione deve già esistere in CloudStack e lo storage deve essere aggiunto come primary storage. I dischi dati devono essere mappati sulle disk offering; tipi misti di controller disco o di schede di rete causano un errore. Una VM in esecuzione può essere importata solo se la VLAN di rete e la compute offering corrispondono; in caso contrario, deve essere prima arrestata.
Source: Apache CloudStack — Informazioni sull'importazione ed esportazione di Instances · consultato il 2026-10-19
Il percorso A si applica quando la destinazione è KVM. La documentazione di NexCMP indica KVM come hypervisor testato, quindi pianifichiamo il percorso A a meno che la tua architettura non mantenga gli host VMware sotto CloudStack. Verifica la versione di CloudStack in uso: le pagine sopra descrivono comportamenti differenti tra la 4.19 e la versione più recente.
Cosa viene migrato e cosa richiede attenzione
Dischi
- Cosa succede
- Convertiti in QCOW2 e importati nel primary storage pool di destinazione (percorso A), oppure mappati sulle disk offering di CloudStack (percorso B).
- Attenzione
- Nel percorso B le dimensioni del disco non vengono modificate se la disk offering è più grande. Lo storage temporaneo durante la conversione del percorso A è secondary storage per impostazione predefinita; è possibile usare il primary storage a tale scopo solo se si tratta di NFS.
Source: Apache CloudStack — Importazione di VM VMware in KVM · consultato il 2026-10-19
Reti
- Cosa succede
- Le reti devono esistere in CloudStack prima dell'importazione. Uno script di discovery elenca le reti vCenter a cui è collegata almeno una VM, consentendo così di creare le reti corrispondenti.
- Attenzione
- virt-v2v non può riconfigurare la rete del guest né modificare il suo indirizzo MAC. Se la subnet di destinazione è diversa, il guest richiederà modifiche dopo la conversione.
Source: libguestfs — Manuale virt-v2v · consultato il 2026-10-19
Guest Linux
- Cosa succede
- Una VM Linux in esecuzione può essere importata tramite il percorso A: CloudStack la clona prima dell'esportazione, venendo così convertita in uno stato crash-consistent.
- Attenzione
- La documentazione di CloudStack consiglia di spegnere prima le VM Linux. virt-v2v non installa nuovi kernel o driver e segnala se manca il supporto a virtio; pertanto il guest deve soddisfare le versioni minime prima della conversione.
Source: libguestfs — Manuale virt-v2v · consultato il 2026-10-19
Guest Windows
- Cosa succede
- Devono essere arrestati correttamente prima dell'importazione tramite il percorso A. I driver virtio vengono ricavati dal pacchetto virtio-win e installati al primo avvio; Windows può riavviarsi quattro o più volte dopo il primo boot.
- Attenzione
- L'Avvio rapido o l'ibernazione impediscono la conversione, e un disco di sistema su Disco dinamico non è supportato. L'importazione di Windows richiede i driver virtio sull'host di conversione.
Source: libguestfs — Manuale virt-v2v · consultato il 2026-10-19
VMware Tools
- Cosa succede
- virt-v2v tenta di rimuovere i VMware Tools.
- Attenzione
- Il manuale indica che la rimozione non funziona in modo affidabile su Windows, dove i Tools potrebbero dover essere rimossi con un altro metodo.
Source: libguestfs — Manuale virt-v2v · consultato il 2026-10-19
Tipo di OS guest
- Cosa succede
- Alla VM importata viene assegnato un tipo di OS guest predefinito.
- Attenzione
- Nella versione 4.19 è CentOS 4.5 (32-bit) e va modificato manualmente; la versione 4.22.1 può mapparlo dall'OS guest di origine se le mappature sono presenti.
Source: Apache CloudStack — Importazione di VM VMware in KVM · consultato il 2026-10-19
Fatturazione e clienti
- Cosa succede
- Piani, prezzi e account clienti vengono configurati in NexCMP, e ciascuna macchina migrata viene associata al cliente corretto.
- Attenzione
- Concordato nella settimana 1 per la tua versione di CloudStack. Si tratta di attività su NexCMP, non di una funzionalità di CloudStack.
Il piano, settimana per settimana
Tipico, adattato al tuo caso specifico. I 30 giorni lavorativi di attività continuativa corrispondono a circa sei settimane di calendario.
Settimana 1 — Inventario e decisioni
Con accesso di sola lettura a vCenter elenchiamo ogni VM: OS guest, dischi, schede di rete, VLAN, snapshot, stato di alimentazione e dipendenze. Scegliamo il percorso A o B, definiamo le ondate e individuiamo le macchine che richiedono attenzioni particolari, come i guest Windows, i dischi di grandi dimensioni ed eventuali licenze vincolate.
Settimana 2 — Preparazione dell'ambiente di destinazione
La zona CloudStack viene verificata o creata: host KVM, storage, reti corrispondenti a quelle VMware. Installiamo virt-v2v sugli host KVM (e nbdkit sugli host Ubuntu), prepariamo i driver virtio per Windows e apriamo i percorsi di rete tra gli host di conversione, vCenter ed ESXi. Se rivendi le macchine, NexCMP viene installato e collegato a CloudStack nella stessa settimana.
Settimana 3 — Progetto pilota
Alcune macchine non critiche, una per ciascuna tipologia di guest presente, seguono la procedura reale. Verifichiamo l'avvio, la connettività di rete, la presenza dei driver corretti, impostiamo il tipo di OS guest e misuriamo i tempi di fermo di ciascuna macchina. L'esito definisce le finestre di intervento per le ondate successive.
Settimane 4 e 5 — Scaglioni di migrazione
Le macchine vengono migrate a gruppi nelle fasce orarie concordate. Ciascun gruppo viene verificato prima di avviare il successivo; le macchine VMware originali rimangono spente ma conservate per consentire un eventuale rollback. Se rivendi le macchine, clienti, piani e prezzi vengono configurati in parallelo su NexCMP, ed è possibile eseguire la fatturazione in parallelo prima del passaggio definitivo.
Settimana 6 — Cutover finale e passaggio di consegne
Vengono migrate le ultime macchine, aggiornata la data di fatturazione (se rivendute) e applicate le modifiche DNS. Documentiamo l'intera procedura, verifichiamo l'hardening e i backup, e rimaniamo a disposizione per la migrazione fino al termine dei 30 giorni lavorativi.
Solo una panoramica di massima. Il piano effettivo scaturisce dalla settimana 1, e l'unico impegno temporale vincolante dell'offerta sono i 30 giorni lavorativi.
I rischi e come li riduciamo
Nessuna migrazione è priva di rischi e non promettiamo downtime zero. Ecco cosa può andare storto e come interveniamo.
Downtime per macchina
Le macchine Windows non possono essere convertite mentre sono accese, mentre una macchina Linux accesa viene convertita in uno stato crash-consistent. CloudStack non specifica la durata esatta di una conversione. La misuriamo durante il pilota e concordiamo quindi una finestra di fermo per ciascun gruppo di macchine.
Mancato successo di una conversione
CloudStack specifica che il successo non è garantito e dipende dal guest. Testiamo ciascuna tipologia di guest nel pilota prima di qualsiasi ondata; la macchina originale rimane intatta fino alla verifica della nuova.
Driver e VMware Tools
Le macchine Windows ricevono i driver virtio durante la conversione, le macchine Linux richiedono il supporto a virtio a monte, e i VMware Tools potrebbero richiedere una rimozione manuale. Tutti questi aspetti vengono verificati per ciascun guest durante il pilota.
Indirizzi IP, indirizzi MAC e DNS
I guest mantengono i propri indirizzi MAC e la configurazione di rete interna, pertanto una subnet di destinazione diversa richiede modifiche all'interno del guest. Censiamo ogni indirizzo nella settimana 1, abbassiamo i TTL dei DNS prima del cutover e informiamo i tuoi clienti in anticipo.
Licenze software dei guest
Windows e il software commerciale all'interno di una macchina potrebbero avere licenze vincolate alla vecchia piattaforma. Li elenchiamo nell'inventario per consentirti di verificare le condizioni con ciascun fornitore prima del passaggio.
Conversioni interrotte
CloudStack specifica che il riavvio dei management server durante una migrazione la interrompe, rendendo necessario riavviare l'importazione da capo. Pianifichiamo le wave al di fuori degli interventi di manutenzione ed evitiamo riavvii mentre una wave è in corso.
Cut-over della fatturazione e rollback
Se rivendi le macchine, la data di passaggio della fatturazione viene concordata con te e i due sistemi vengono inizialmente eseguiti in parallelo. Gli originali su VMware vengono conservati finché non confermi che il passaggio è concluso, garantendo a ogni gruppo una procedura di ripristino.
Chi fa cosa
Accesso in sola lettura a vCenter e un elenco delle macchine che consideri critiche
- L'esperto esegue
- Inventaria ogni VM e pianifica le wave
Accesso all'ambiente CloudStack e agli host KVM, o all'hardware necessario per configurarli
- L'esperto esegue
- Prepara la zona, le reti e gli host di conversione
I pacchetti VDDK e virtio necessari per il percorso scelto, laddove i rispettivi fornitori ne richiedano il download manuale
- L'esperto esegue
- Li installa e li collauda sugli host di conversione
Finestre di fermo concordate e comunicazioni ai tuoi clienti
- L'esperto esegue
- Esegue il pilota e le wave, verificando ogni macchina al termine
Le tue decisioni sui prezzi, se rivendi le macchine
- L'esperto esegue
- Configura piani, clienti e fatturazione in NexCMP e gestisce il periodo in parallelo
Cosa include il periodo di 30 giorni lavorativi
La migrazione fa parte dell'upgrade a NexCMP Source: una tantum di $499 che include il codice sorgente completo (server Rust, portale e admin Vue, node agent Go, CLI, script di build), il diritto di modificare e compilare la propria versione senza limiti, 12 mesi di nuove release del sorgente, tutte le app e 30 giorni lavorativi di lavoro continuo con un ingegnere esperto.
In quei 30 giorni lavorativi l'esperto esegue la migrazione da VMware ad Apache CloudStack senza costi aggiuntivi. In alternativa o in aggiunta, lo stesso tempo può essere impiegato per migrare da WHMCS o da un altro sistema, oppure per un setup completo da zero e la compilazione delle tue app. Il conteggio ha inizio quando avvii i lavori con l'esperto ed è visibile nella pagina della tua licenza. Il supporto per la migrazione copre gli stessi 30 giorni.
NexCMP Free non include questo servizio. Free è gratuito per un anno con tutti i moduli e nessun supporto tecnico, include solo la risoluzione di bug del codice sorgente e si rinnova a $99 all'anno.
Da VMware a CloudStack — domande frequenti
Quanto costa?
È incluso in NexCMP Free?
Quali versioni di CloudStack e VMware sono supportate?
Le mie macchine virtuali subiranno downtime?
È possibile convertire qualsiasi VM?
Dovrò mantenere VMware al termine della migrazione?
Cosa devo fornire?
Fonti e note
Le dichiarazioni tecniche provengono dalla documentazione ufficiale di Apache CloudStack e dal manuale di virt-v2v. La documentazione varia tra le release, quindi verifica la versione in uso. L'indicazione su 4.19 proviene dalla documentazione della versione 4.19, che introduce la pagina VMware-to-KVM con 'As of CS 4.19'. VMware, WHMCS, HostBill, Blesta, Paymenter, StackBill, Virtualizor e Apache CloudStack sono marchi dei rispettivi proprietari. NexCMP è indipendente e non è affiliata né approvata da essi.
Lascia VMware con un ingegnere al tuo fianco
Passa a NexCMP Source per $499 e avvia i tuoi 30 giorni lavorativi, oppure chiedi prima a [email protected] informazioni sul tuo ambiente.
Ultimo aggiornamento: