combined.expert - Guida alla migrazione da XenServer 8.4 a XCP-ng 8.3 - Parte 1

La migrazione da Citrix XenServer 8.4 a XCP-ng 8.3 rappresenta un passaggio strategico per le organizzazioni che desiderano mantenere un’infrastruttura basata su tecnologia Xen, riducendo al contempo la dipendenza da licenze e costi ricorrenti.

XCP-ng è un fork open-source di XenServer, sviluppato con l’obiettivo di garantire piena compatibilità a livello di hypervisor, toolstack (xapi) e gestione del pool. Dal punto di vista architetturale, il funzionamento rimane sostanzialmente invariato: struttura del pool, Storage Repository (SR), networking, VM lifecycle e comandi xe operano secondo lo stesso modello.

Questo consente agli amministratori già esperti in XenServer di gestire XCP-ng senza formazione supplementare significativa e senza dover rivedere processi operativi, procedure di backup o logiche di gestione esistenti. La migrazione, se pianificata correttamente, può essere eseguita in modo controllato e con impatto minimo sull’operatività.

In questo articolo del blog spieghiamo in modo dettagliato i requisiti di sistema, la preparazione di un file ISO XCP-ng personalizzato e la procedura di aggiornamento del pool da XenServer a XCP-ng.

Nel prossimo articolo vedremo come aggiornare le VM dai XenServer VM Tools ai XCP-ng guest tools per Windows e Linux. In questo modo, la migrazione non si limita all’host, ma include anche la completa integrazione delle VM nella nuova piattaforma.

Requisiti di sistema

XCP-ng viene generalmente implementato su hardware di classe server, ma supporta anche molti modelli di workstation e laptop.

XCP-ng 8.3 condivide un elenco di compatibilità con XenServer 8.4. Pertanto, i dispositivi elencati nell'elenco di compatibilità hardware di XenServer sono supportati, con rare eccezioni.

https://hcl.xenserver.com/

Le eccezioni includono dispositivi che richiedono componenti software proprietari per funzionare (ad esempio driver closed source). Tali dispositivi non impediscono l'uso di XCP-ng, ma le loro funzionalità non possono essere sfruttate.

Molti dispositivi non presenti nell'HCL funzionano perfettamente con XCP-ng. A differenza di alcuni hypervisor, XCP-ng non richiede l'uso di server provenienti da un elenco ristretto. La maggior parte del supporto hardware dipende dai driver del kernel Linux e dai driver dei fornitori che coprono una vasta gamma di dispositivi.

L'assenza dall'HCL significa semplicemente che test sistematici su quel dispositivo non sono stati eseguiti, quindi non e possibile offrire lo stesso livello di garanzia offerto per i dispositivi presenti nell'HCL. Tuttavia, la vasta comunità di utenti utilizza XCP-ng su una gamma di hardware che va ben oltre quella dell'HCL ufficiale.

Prestiamo particolare attenzione alla sicurezza su hardware più vecchio con vulnerabilità hardware. L'hardware più vecchio, sebbene di solito funzioni ancora molto bene - e noi siamo tutti favorevoli all'utilizzo dell'hardware esistente finché dura piuttosto che all'acquisto di nuove macchine - potrebbe non ricevere aggiornamenti di sicurezza relativi all'hardware dal proprio fornitore. In particolare quelli relativi agli attacchi side-channel (Spectre, Meltdown e tutto ciò che ne è derivato). In questo caso, è possibile utilizzare XCP-ng, ma senza aspettarsi una protezione contro questo tipo di vulnerabilità, perché semplicemente non dipende da XCP-ng (o da qualsiasi altro hypervisor): dipende dal produttore hardware.

Ulteriori informazioni sono disponibili sulla pagina ufficiale: https://docs.xcp-ng.org/installation/hardware/

Di seguito sono riportate le specifiche hardware consigliate per XCP-ng.

XCP-ng deve essere installato su una macchina di classe server x86 a 64 bit dedicata all'hosting di macchine virtuali. Crea una partizione Linux sicura utilizzando un kernel abilitato per Xen, che gestisce le interazioni tra le macchine virtuali e l'hardware fisico.

CPU: una o più CPU x86 a 64 bit, minimo 1.5 GHz; si consigliano CPU multi core da 2 GHz o più veloci. Per eseguire macchine virtuali Windows o versioni recenti di Linux, è necessario un sistema basato su Intel VT o AMD-V x86 a 64 bit con una o più CPU.

Memoria RAM: minimo 2 GB, consigliati 4 GB o più. Una quantità fissa di RAM viene allocata al dominio di controllo (dom0). L'allocazione ottimale dipende dal carico di lavoro. Per provare XCP-ng con 2-3 macchine virtuali consigliamo almeno 16 G di RAM. I nostri host hanno un minimo di 384 GB di RAM e il carico di lavoro è distribuito su due pool distinti e ridondanti.

Spazio su disco: storage locale (P-ATA, S-ATA, SCSI) con un minimo di 46 GB, consigliati 70 GB o più. Accesso SAN tramite HBA (non software) in caso di installazione con avvio multipath da SAN. Noi utilizziamo dischi locali in RAID 1 (2 x 146 GB) per XCP-ng e storage SAN connesso tramite Fibre Channel per le macchine virtuali.

ATTENZIONE: l'installazione su drive USB e SD Card è fortemente sconsigliata a causa delle intense operazioni di scrittura in XCP-ng:

• Database xapi: subisce frequenti modifiche, con conseguenti operazioni di scrittura estese che potrebbero ridurre la durata dell'unità USB. Il database xapi mantiene lo stato di tutte le operazioni XCP-ng e viene replicato su tutti gli host.
• Logging: XCP-ng genera un volume elevato di registri. Valutare l'utilizzo di un servizio syslog remoto come alternativa.

Rete: scheda di rete da 100 Mbit/s. Consigliato: una o più schede di rete da 1 GBit/s o 10 GBit/s per ridondanza, trasferimenti dati più veloci, inclusi P2V, importazione/esportazione e migrazioni live di macchine virtuali.

NOTA: XCP-ng 8.2 richiede una rete IPv4 per il traffico di gestione e archiviazione. A partire da XCP-ng 8.3, la rete di gestione supporta anche IPv6.

Ulteriori informazioni sono disponibili sulla pagina ufficiale: https://docs.xcp-ng.org/installation/requirements/

Requisiti per pool

Oltre ai prerequisiti hardware elencati in precedenza, esistono ulteriori prerequisiti di configurazione per un host che si unisce a un pool:

• Indirizzo IP statico (o lease DHCP con riservazione). Questo requisito si applica anche ai server che forniscono storage NFS o iSCSI condiviso.
• Orologio di sistema sincronizzato con il master del pool (ad esempio tramite NTP).
• Non deve far parte di un pool esistente.
• Nessuna VM in esecuzione o sospesa, né operazioni VM attive (arrestare le VM prima dell'aggiunta).
• Nessun storage condiviso configurato.
• Non può avere un'interfaccia di gestione «bonded». Riconfigurare l'interfaccia di gestione e riconfigurarla su una scheda di rete fisica singola prima di aggiungere il server al pool. Una volta che l'host è entrato a far parte del pool, è possibile riconfigurare nuovamente l'interfaccia di gestione.
• Deve eseguire la stessa versione di XCP-ng, con lo stesso livello di aggiornamento, dei server già presenti nel pool.

I pool di risorse possono avere host con interfacce di rete fisiche e capacità di storage locale diverse. In pratica, spesso è difficile ottenere più server con CPU identiche, pertanto sono consentite piccole variazioni. Se si desidera che l'ambiente abbia host con CPU diverse nello stesso pool di risorse, è possibile forzare l'aggiunta a un pool utilizzando la CLI.

Pool omogenei: un pool di risorse omogeneo è un insieme di host con CPU identiche. Gli host in un pool omogeneo devono avere CPU identiche, inclusi fornitore, modello e caratteristiche.

Pool eterogenei: tecnologie quali Intel FlexMigration o AMD Extended Migration consentono di creare pool eterogenei. Queste tecnologie forniscono mascheramento o livellamento della CPU, il che significa che è possibile configurare una CPU in modo che sembri fornire una marca, un modello o un set di caratteristiche diversi da quelli effettivi. Queste funzionalità consentono di creare pool di host con CPU diverse e continuare a supportare migrazioni live sicure.

La verifica di flag CPU è possibile tramite la CLI:

Punti importanti da sapere prima dell'installazione

È possibile aggiornare l'infrastruttura XenServer a XCP-ng senza perdere NESSUNA impostazione esistente (SR, VM, reti, ecc.).

Leggere attentamente le informazioni seguenti!

Aggiornare e riavviare SEMPRE PRIMA il pool master.

NON utilizzare la modalità di manutenzione in XenCenter. Questa modalità sposta il ruolo pool master su un altro host, cosa che deve essere evitata durante la procedura di aggiornamento a XCP-ng.

Se High Availability fosse abilitato, disabilitarlo prima dell'aggiornamento.

Espellere i CD dalle macchine virtuali prima dell'aggiornamento per evitare problemi. Possiamo utilizzare il comando CLI:

È molto importante assicurarsi che il clustering non sia abilitato sul pool. Si tratta di una funzionalità che si basa su software proprietario e che non è disponibile in XCP-ng. Se questa funzionalità fosse abilitata prima dell'aggiornamento, xapi non sarà in grado di avviarsi a causa di dati imprevisti nel database. Maggiori informazioni sono disponibili a questo indirizzo: https://github.com/xcp-ng/xcp/issues/94#issuecomment-437838544

Se si disponesse già di un pool XCP-ng, non provare ad aggiungere un host che esegue XenServer. Verrà visualizzato un errore «Licenza incompatibile». Aggiornare prima l'host a XCP-ng, quindi aggiungerlo al pool esistente.

Prima di procedere, è importante assicurarsi che il servizio xapi attualmente in esecuzione sull'host sia compatibile con la versione fornita da XCP-ng. Per verificarlo, aprire una sessione terminal sul server host ed eseguire il comando seguente:

Questo comando visualizza informazioni dettagliate sul pacchetto xapi-core installato, compreso il numero di versione. Controllare la versione xapi disponibile negli aggiornamenti XCP-ng. La compatibilità è essenziale perché l'ISO di installazione XCP-ng può aggiornare solo gli host XenServer la cui versione xapi è uguale o inferiore alla versione inclusa in XCP-ng. Se la versione xapi fosse superiore, il processo di aggiornamento non è possibile.

Per esempio, il file ISO di XCP-ng 8.3 LTS xcp-ng-8.3.0-20250606.iso di giugno 2025 fornisce la versione xapi 25.6. A dicembre 2025, XenServer 8.4 esegue xapi 25.33. L'aggiornamento con il file ISO standard non è possibile, ma XCP-ng è flessibile e possiamo creare il nostro file ISO personalizzato con gli ultimi aggiornamenti. In questo modo otteniamo un file ISO con una versione XAPI più recente.

Per gestire XCP-ng sono disponibili due prodotti: XCP-ng Center (l'equivalente di XenCenter) e Xen Orchestra, un'interfaccia web che è possibile installare su un server Linux o disponibile come appliance.

IMPORTANTE: XCP-ng Center non può connettersi a pool XenServer e Citrix XenCenter non può connettersi a pool XCP-ng. Al contrario, Xen Orchestra può gestire pool XCP-ng e pool XenServer.

Creare un file ISO aggiornato di XCP-ng

Per questa operazione usiamo il nostro portatile con Linux Mint oppure una macchina virtuale.

Installazione Docker

Procediamo con l’aggiornamento dei repository, l’installazione di Docker, l’attivazione del servizio e l’abilitazione dell’utente corrente all’esecuzione dei comandi Docker.

Al termine, effettuare il logoff e di nuovo il login. In questo modo l'utente è membro attivo del gruppo Docker.

Clonare build repo di XCP-ng

Effettuiamo il clone del repository Git che include gli script di build dell’immagine di installazione e impostiamo la directory di lavoro per le operazioni successive.

Avviare build container

Scarichiamo l’immagine Docker contenente l’ambiente ufficiale di build XCP-ng e avviamo un container temporaneo montando la directory di lavoro locale, così da poter generare l’immagine personalizzata in un ambiente isolato e coerente.

I comandi seguenti devono essere eseguiti dalla cartella create-install-image:

• -v $PWD:/build collega il nostro repository al container
• Ora ci troviamo nell'ambiente di compilazione compatibile con CentOS7
• Tutte le dipendenze (lorax, rpm-build, dracut) sono già presenti

Installiamo le utilità richieste nel container:

Creare un'immagine di installazione

Accediamo alla directory di build ed eseguiamo lo script di generazione dell’immagine di installazione, specificando il repository degli aggiornamenti XCP-ng e il nome del file di output.

• srcurl → Repository per pacchetti XCP-ng (base + aggiornamenti)
• 8.3:updates → assicura che xapi-core ≥ 25.33 sia incluso in install.img

Creare il file ISO

Dalla directory del container avviamo lo script di generazione della ISO completa, indicando il repository 8.3 updates, il volume label dell’immagine, il file ISO di output e includendo l’immagine install-8.3.updates.img per integrare direttamente gli aggiornamenti nell’installer.

Il file ISO è pronto e possiamo copiarlo sulla chiavetta USB come spiegato nel capitolo successivo.

Creare una chiavetta USB avviabile con XCP-ng

Su Linux Mint utilizziamo l’utilità Ventoy per scrivere il file ISO XCP-ng sulla chiavetta USB. Per prima cosa verifichiamo la configurazione del disco con il comando seguente:

sda → sda1 è la nostra chiavetta USB.

Prima di poter scrivere dati dobbiamo eseguire il comando seguente:

A questo punto copiamo Ventoy sulla chiavetta USB:

Ora possiamo copiare il file ISO che abbiamo appena creato sulla chiavetta USB. All'avvio potremo scegliere il file dal menu di Ventoy.

Preparazione dell'aggiornamento

Prima di iniziare con l’aggiornamento a XCP-ng, è indispensabile verificare che il pool XenServer sia in ottima salute e non ci siano problemi in sospeso. Inoltre, come per qualsiasi modifica all’infrastruttura informatica, verificate il backup. Non effettuate modifiche senza il backup.

Abbiamo preparato una breve lista di controllo per aiutarvi a concludere l’aggiornamento senza disastri.

Backup dei metadata del pool: include configurazioni delle VM, reti, storage e parametri del pool.

Backup delle VM: snapshot delle VM o esportazione OVF/backup completo dei dischi virtuali o meglio ancora backup completo tramite il programma di backup che usate giornalmente.

Verifica degli snapshot: identifica snapshot ancora in uso, elimina i più vecchi. L'ideale sarebbe effettuare l'aggiornamento senza nessun snapshot.

Backup delle configurazioni di rete: interfacce, bonding, VLAN, PIF/SR tagging.

Stato del pool: verificare che tutti gli host siano online.

Stato delle VM: nessuna VM in stato «sospeso» o «pending».

Controllo delle licenze XenServer: le licenze non sono richieste dopo la conversione a XCP-ng.

Versione di xapi e configurazioni personalizzate: Elenca le configurazioni personalizzate che potrebbero richiedere attenzione. Verifica la versione in esecuzione di xapi.

Stato dello storage: verifica lo stato dei Storage Repository (SR), conferma che tutte le VM siano su SR accessibili.
Piano di emergenza: prepara piani di fallback e disaster recovery.

Consigli utili

Backup del pool metadata: il database del pool è critico. Senza di esso è difficile ripristinare la struttura delle VM e delle configurazioni → esegui il backup prima di qualsiasi altra operazione.

Versione xapi: XCP-ng utilizza una versione più aperta e aggiornata di xapi. Alcuni plug-in commerciali XenServer potrebbero non essere supportati. Verifica che qualsiasi integrazione personalizzata funzioni correttamente dopo la migrazione.

Aggiornamenti dei VM Guest Tools: XenServer VM Tools e XCP-ng Guest Tools sono diversi. Dopo la migrazione fisica, dovremo aggiornare i Guest Tools nelle VM (Windows + Linux).

Snapshot e storage: evitare snapshot troppo datati. Pacchetti incoerenti sul SR possono causare errori durante la conversione.

VM: durante l'aggiornamento, l'host non deve eseguire nessuna VM. Spostiamo le VM su di un altro host nel pool (senza utilizzare la modalità manutenzione) oppure arrestiamo le VM.

Aggiornamento

Ora siamo pronti per l'aggiornamento del pool master da XenServer 8.4 a XCP-ng 8.3. Assicuriamoci che l'host non esegua nessuna VM. Inseriamo la chiavetta USB e riavviamo il pool master:

Selezione del layout della tastiera:

Confermare con OK:

Accettare il contratto di licenza:

Il programma di installazione riconosce XenServer e propone l'aggiornamento a XCP-ng:

Il programma di installazione crea un backup dell'installazione esistente di XenServer:

Selezionare Local media come sorgente di installazione:

Consigliamo di verificare la sorgente di installazione:

Verifica eseguita con successo:

A questo punto possiamo procedere con l'installazione vera e propria di XCP-ng. XenServer verrà sovrascritto da XCP-ng e tutte le impostazioni saranno riprese automaticamente.

Installazione in corso:

Installazione eseguita con successo. Rimuovere la chiavetta USB e riavviare l'host.

Ora possiamo spostare le VM sul nuovo host XCP-ng e procedere con l’aggiornamento degli host rimanenti nel pool. L'aggiornamento degli host nel pool funziona esattamente come per il master: l'host non deve eseguire nessuna VM, avviamo da chiavetta USB, eseguiamo l'aggiornamento, rimuoviamo la chiavetta USB e riavviamo l'host. E cosi via, finché tutti gli host nel pool non saranno aggiornati.

Per amministrare il pool XCP-ng dobbiamo utilizzare XCP-ng Center (XenCenter non si può connettere a XCP-ng) oppure Xen Orchestra. Xen Orchestra è un'interfaccia web che può amministrare sia XenServer 8.4 che XCP-ng 8.3.

Per adesso non dobbiamo preoccuparci dei VM Guest Tools. XenServer VM Tools sono compatibili con XCP-ng. Possiamo migrare XenServer VM Tools a XCP Guest Tools in un secondo momento.

Approfondiremo questo tema nel prossimo articolo tecnico della serie combined.expert che pubblicheremo il mese prossimo. Tratteremo i temi seguenti:

• Opzione «Manage Citrix PV drivers via Windows Update»
• UEFI Boot
• Rimozione di XenServer VM Tools per Windows e Linux
• Installazione di XCP-ng Guest Tools su Windows e Linux
• Rimozione di dispositivi «fantasma» (Cleanup ghost devices)
• Modifica del programma di installazione per sistemi operativi non riconosciuti automaticamente

Conclusione

Che si tratti di XenServer, VMware o Hyper-V, oggi molte infrastrutture virtuali presentano lo stesso problema: costi per licenze in costante aumento, complessità crescente e margini di controllo sempre più ridotti.

Dopo oltre venti anni di esperienza nella progettazione e gestione di infrastrutture virtuali aziendali, sappiamo che una piattaforma deve essere prima di tutto stabile, performante e sostenibile nel tempo. La scelta dell’hypervisor non è solo tecnica: è una decisione strategica che incide sui costi operativi per anni.

Migrare verso una soluzione più aperta e flessibile significa ridurre la dipendenza da vendor, pianificare meglio gli investimenti e ottenere un risparmio concreto nel medio-lungo termine — senza compromettere affidabilità e continuità operativa.

Se desiderate valutare come ottimizzare la vostra infrastruttura virtuale, ridurre i costi e costruire una base solida per il futuro, contattateci per un’analisi tecnica personalizzata. Metteremo a vostra disposizione la nostra esperienza per individuare la strategia più efficace e sostenibile per la vostra realtà.