Migrazione di una macchina virtuale con vSphere vMotion

Con il vMotion, l’intero stato di una macchina virtuale viene traslato da un host ad un altro. Per stato di una VM si intende il contenuto della sua memoria e tutte le informazioni relative all’hardware, quali BIOS, elenco dispositivi, CPU, interfacce di rete e relativi MAC-address. Prima di iniziare la migrazione della VM, il vCenter Server esegue una pre-verifica dei requisiti: gli avvisi appariranno in giallo, e consentiranno di proseguire, mentre gli errori appariranno in rosso, e non consentiranno la migrazione.

Procedura tramite vSphere Client

• Fare clic con il tasto destro sulla macchina accesa e selezionare la voce Migrate.
• In caso di storage condiviso, nella procedura guidata selezionare la voce Change host. In tal caso, dopo la migrazione, i file della VM saranno sempre nello stesso storage. Se invece la VM risiede su un datastore locale, sarà necessario procedere a un cambio simultaneo di host e datastore, selezionando la voce Change both host and datastore.
• È possibile impostare la priorità del vMotion utilizzando le opzioni High Priority e Standard Priority.
  • High Priority – negli host con ESX/ESXi versioni 4.1 e successive, vCenter Server cerca di riservare le risorse ad entrambi gli host di origine e di destinazione, affinché siano disponibili per tutte le migrazioni simultanee. Il vCenter Server garantisce una quota maggiore di risorse CPU alle migrazioni ad alta priorità rispetto alle migrazioni a priorità standard. In ogni caso le migrazioni saranno portate a termine indipendentemente dalle risorse riservate.
  • Standard Priority – negli host con ESX/ESXi versioni 4.1 e successive, vCenter Server riserva le risorse ad entrambi gli host di origine e di destinazione, affinché siano rese disponibili per tutte le migrazioni simultanee. Il vCenter Server concede una quota minore di risorse CPU alle migrazioni a priorità standard rispetto alle migrazioni ad alta priorità. In ogni caso le migrazioni saranno portate a termine indipendentemente dalle risorse riservate.

Procedura tramite vSphere Web Client

• Fare clic con il tasto destro sulla macchina accesa e selezionare la voce Migrate.
  
  
  
  
• In caso di storage condiviso, nella procedura guidata selezionare la voce Change host. Così facendo, dopo la migrazione i file della VM saranno sempre nello stesso storage. Se invece la VM risiede su un datastore locale, sarà necessario procedere con un cambio simultaneo di host e datastore, selezionando la voce Change both host and datastore.
  
  
  
  
• È possibile impostare la priorità del vMotion in base a due opzioni.
  • Reserve CPU for optimal VMotion performance - il vCenter Server cerca di riservare risorse ad entrambi gli host di origine e di destinazione, affinché queste siano disponibili per tutte le migrazioni eseguite contemporaneamente. Sono garantite elevate risorse CPU. Se tali risorse non sono disponibili, l’operazione di vMotion non viene avviata.
  • Perform with available CPU resources - il vCenter Server cerca di riservare risorse ad entrambi gli host di origine e di destinazione, affinché queste siano disponibili per tutte le migrazioni eseguite contemporaneamente. Per l’operazione, sono assegnate risorse CPU limitate. Se non c’è disponibilità di risorse, la durata del vMotion può essere estesa.
    
    

Requisiti per le migrazioni con vSphere vMotion

La migrazione di una VM richiede una corretta configurazione della rete sia per l’host sorgente, sia per quello di destinazione.

In particolare si consiglia quanto di seguito indicato.

• Su ogni host, configurare un’interfaccia VMkernel per il vMotion.
• Utilizzare interfacce fisiche Gigabit per il vMotion; è preferibile che gli host abilitati al vMotion siano attestati su una rete Gigabit Ethernet.
• Se nell’host sono disponibili solo due interfacce di rete:
• dedicare l’interfaccia gigabit al vMotion, e nell’altra interfaccia utilizzare le VLAN per dividere il traffico delle VM dal traffico di management;
• in alternativa, per una miglior disponibilità, combinare entrambe le interfacce in teaming, e utilizzare le VLAN per la separazione del traffico: una o più VLAN per il traffico delle VM e una per il vMotion;
• Assicurarsi che la rete virtuale su cui è attestata una VM sia presente anche nell’host di destinazione; durante la migrazione il vCenter Server assegna le macchine virtuali ad un determinato virtual switch sulla base del nome assegnato al port group, nome che deve avere corrispondenza tra host sorgente e host di destinazione.
• Perché la migrazione con vMotion possa andare avanti, la VM non deve trovarsi su switch privi di uplink (virtual intranet).

Per quanto riguarda gli host, i requisiti per una migrazione vMotion sono indicati di seguito.

• Se si esegue il vMotion classico, con cambio del solo host, è richiesta la visibilità dello stesso datastore da entrambi gli host (sorgente e destinazione).
• Compatibilità tra host a livello di CPU; ad esempio, se la CPU dell’host sorgente supporta le estensioni SSE4.1 e questo supporto non esiste nella CPU di destinazione, la migrazione vMotion fallisce.
• Se la VM ha dischi RDM, questi devono essere visibili e accessibili anche dall’host di destinazione; inoltre i file di mapping dei dischi RDM devono trovarsi nello stesso datastore.
• La VM da migrare non può avere immagini CDROM e floppy montate.

Funzionamento di vSphere vMotion

• Appena avviata l’operazione di vMotion (Change Host), la memoria della macchina virtuale viene copiata dall’host sorgente a quello di destinazione, attraverso la rete, con gli utenti che possono continuare ad accedere alla VM. Di conseguenza è possibile una modifica di pagine di memoria anche durante il vMotion; il meccanismo prevede che di queste modifiche sia tenuta traccia nell’host sorgente, su una memory bitmap.
• Prima che sia completamente trasferita sull’host di destinazione, la VM è portata in uno stato di quiescenza, dove non sono più possibili modifiche. Nella fase di quiescenza sono trasferiti sull’host di destinazione lo stato dei dispositivi e la memory bitmap.
• Non appena entra in quiescenza, la VM viene avviata nell’host di destinazione; la rete è informata del cambio di switch tramite protocollo RARP (Reverse ARP) e, terminata la fase di sincronizzazione del punto precedente, gli utenti potranno accedere alla macchina ospitata sul nuovo host.

Flag NX/DX

Nelle impostazioni di una macchina virtuale, alla voce CPUID Mask è possibile impostare le funzioni AMD No eXecute (NX) e Intel eXecute Disable (XD). Si tratta di due tecnologie di sicurezza, implementate a livello di CPU, che seguono lo stesso obiettivo: marcare le pagine di memoria come “data-only” per evitare l’esecuzione di codice dannoso o attacchi di buffer overflow. Il meccanismo prevede l’isolamento delle aree di memoria da dedicare alle istruzioni della CPU oppure ai dati. Se un’area di memoria è contrassegnata con il flag NX o XD, non vi possono risiedere istruzioni, ma solo dati.

Se la tecnologia è abilitata su un host sorgente, vMotion richiede che sia abilitata anche sull’host di destinazione. Sulle macchine virtuali il flag NX/DX è esposto in maniera predefinita, pertanto se l’host utilizza questa tecnologia, anche i sistemi operativi guest possono utilizzarla. Disattivare l’esposizione del flag sulle macchine virtuali aumenta la compatibilità tra host per le operazioni di vMotion, al costo di disattivare le relative funzioni di sicurezza.

Nascondere l’esposizione del flag NX/XD con vSphere Client

• Entrare nelle impostazioni della VM e andare nel tab Options.
• Selezionare la voce CPUID Mask e impostare l’opzione Hide the NX/DX flag from guest. La modifica non può essere eseguita a caldo (con la macchina in esecuzione).

Nascondere l’esposizione del flag NX/XD con vSphere Web Client
Entrare nelle impostazioni della VM.
Selezionare la CPU e impostare l’opzione Hide the NX/DX flag from guest nel relativo campo CPUID Mask. La modifica non può essere eseguita a caldo (con la macchina in esecuzione).