This post is also available in: Inglese

Come già scritto in un post precedente, con il nuovo VMware vSphere 6.0 sono state introdotte anche numerose migliorie al vMotion al fine di aumentare la mobilità delle virtual machine e superare i limiti ed i confini attuali.

Anche se la long distance vMotion potrebbe sembrare la novità più grande (sicuramente è quella più di effetto visto che sulla carta permetterebbe di spostare una VM accesa tra due continenti), secondo me la vera rivoluzione è rappresentata dal cross vCenter vMotion (che veramente permette di superare i confini dei datacenter… e tecnicamente rappresenta la vera novità).

Spostare una VM tra due vCenter è decisamente una sfida, ma è l’unico modo per liberare una VM dai suoi confini ed aumentarne la libertà (e comunque può anche essere alla base per poter poi implementare un long distance vMotion)… Come il primo vMotion 1.0 ha rappresentato una rivoluzione, permettendo di liberare una VM dai confini di un singolo host (e permettendo poi di implementare numerosi nuovi servizi), questo nuovo vMotion libera le VM dai confini dei datacenter e anche dai confini geografici e permetterà di implementare una nuova generazione di servizi.

Come già scritto nel post precedente, esistono numerosi requisiti e vincoli (in particolare quelli riguardo la banda minima e la massima latenza) che vanno considerati e pianificati.

Esistono anche due casi diversi di vMotion cross-vCenter:

• Stesso dominio SSO sia per il vCenter Server sorgente che per quello di destinazione: in questo caso è possibile eseguire il vMotion direttamente da Web Client (oppure, ovviamente, anche da CLI) dal quale si possono vedere sia l’infrastruttura sorgente che quella di destinazione.
• Diversi domini SSO per i due vCenter: in questo caso ci troviamo di fronte a due infrastrutture che non si conoscono e l’unico modo per eseguire un vMotion è tramite le API di VMware (vedere questo post per un esempio scritto in PowerCLI).

Dal mio punto di vista il secondo tipo di vMotion cross vCenter è quello decisamente più interessante visto che permette di spostare a caldo una VM tra due infrastrutture che non si “conoscono”… più libertà di movimento di così!

Notare che questo è possibile nella RC e suppongo che lo sia anche nella GA di vSphere 6.0, ma bisognerà poi vedere se sarà supportato fin da subito e se verrà fornito uno script ufficiale per eseguire questo spostamento.

Secondo la KB 2106952 (Cross vCenter vMotion requirements in VMware vSphere 6.0) pare che il requisito del singolo dominio di SSO (e il fatto che i vCenter siano in linked mode tra di loro) sia stringente nella GA!

Al momento l’unico script che ho trovato è quello di Willian Lam, descritto nel suo post: Did you know of an additional cool vMotion capability in vSphere 6.0?

Lo stesso che ho usato nell’ultimo VMUG.IT Meeting durante la demo del nuovo vMotion (demo eseguita con la RC). In realtà lo script non mi funzionava ed ho dovuto aggiungere le righe evidenziate in rosso (all’interno delle parti rilevanti) per specificare la cartella di destinazione della VM all’interno dell’inventario VM & Template (per comodità ho scelto di usare quella standard per ogni “sconosciuta” VM importata):

# Source VM to migrate
$vm = Get-View (Get-VM -Server $sourceVCConn -Name $vmname) -Property Config.Hardware.Device
# Dest Datastore to migrate VM to
$datastore = (Get-Datastore -Server $destVCConn -Name $datastorename)
# Dest Cluster to migrate VM to
$cluster = (Get-Cluster -Server $destVCConn -Name $clustername)
# Dest ESXi host to migrate VM to
$vmhost = (Get-VMHost -Server $destVCConn -Name $vmhostname)
# Dest Folder to migrate VM to
$vmfolder = (Get-Folder -Server $destVCConn -Name "Discoved virtual machine")
...
# Relocate Spec for Migration
$spec = New-Object VMware.Vim.VirtualMachineRelocateSpec
$spec.datastore = $datastore.Id
$spec.host = $vmhost.Id
$spec.folder = $vmfolder.Id
$spec.pool = $cluster.ExtensionData.ResourcePool


Con la GA qualcosa potrebbe ulteriormente cambiare, ma mi auguro anche che verrà fornito uno script ufficiale (o che venga considerato quello di Lam come quello ufficiale).

Per curiosità ho avuto vari problemi prima di riuscire a far andare lo script e questo nuovo vMotion… Il più curioso è stato quello relativo alle VMware Tools… benché non servano per il vMotion, durante l’installazione mi era rimasto pendente lo stato di completamento delle stesse (con il menù relativo che mostrava “End VMware Tools installation”) e il vMotion si rifiutava di funzionare. Ho dovuto spegnere la VM per sbloccare questa situazione… da lì in poi ha funzionato senza grossi problemi (anche con le VMware Tools disattivate o con la VM che era in fase di reboot).

Ricordiamoci poi tutti i vincoli e requisiti tipici di un vMotion… ad esempio l’assenza di risorse solo locali e non migrabili/copiabili. Tipicamente il lettore CD/DVD è uno di questi casi. Curiosamente anche se solo definito e non collegato mi è stato bloccante per il vMotion (magari questo comportamento verrà risolto nella GA)… il consiglio è quindi sempre quello di impostarlo nella modalità client. Tra l’altro il WebClient lo segnalava durante il vMotion, quindi sarebbe più che altro bloccante per operazioni da riga di comando.

Ovviamente poi serve almeno un’interfaccia vmkernel marcata come vMotion per ogni host (o almeno per quelli sorgente e destinazione). Rilevante che a partire da vSphere 6.0 la rete di vMotion più essere di livello 3 e ruotabile… anzi è previsto un vero e proprio TCP/IP dedicato (ad esempio per avere un differente gateway).

Per quanto riguarda invece la rete delle VM, questa deve rimanere ancora una rete di livello 2 (del resto il vMotion non riconfigura gli IP all’interno della VM). Il modo più semplice (ma non necessariare il più economico) sarebbe di utilizzare NSX e le sue Logical Network… ma qualunque tipo di L2 VPN o stretched LAN andrebbe bene.

Per quanto riguarda la possibilità di avere MAC address virtuali duplicati e di comple mitigare questa possibilità, rimando al post precedente o al post (in inglese): Duplicate MAC Address concerns with xVC-vMotion in vSphere 6.0.

E il futuro?

Come scritto questo nuovo tipo di vMotion rappresenta una vera rivoluzione ed è il primo passo per implementare nuovi servizi e funzionalità.

Ovviamente il primo passo potrebbe essere integrarlo, in qualche modo, all’interno dell’interfaccia grafica… esistono sicuramente delle complicazioni, ma sviluppare un plugin che implementi una sorta di “federazione di risorse” o vista multi vCenter non lo vedo così difficile.

Meno semplice tecnicamente, ma sicuramente necessario, sarà implementare un vMotion tra un vCenter e vCloud Air e viceversa (e ovviamente tra vCenter e un altro vCloud powered)… questo veramente sarebbe la base per implentare seriamente una soluzione di single cloud ibrido (almeno per queanto riguarda lo IaaS secondo VMware).

Già oggi è possibile spostare le VM tra un cloud privato (o anche solo un vCenter) e un vCloud pubblico, ma solo a freddo… poter svolgere questa operazione a caldo sarebbe una grande discriminante a favore del cloud ibrido.

Questa possibilità aprirebbe anche dei dubbi sulla compatibilità dei processori (ovviamente non sarà possibile migrare tra AMD ed Intel o viceversa): come conoscere la baseline EVC del cloud pubblico? Forse sarebbe avere una sola modalità di compatibilità magari a livello di VM (come avviene ad esempio in Hyper-V) piuttosto che tante diverse a livello di cluster? Tutte domande aperte ma che diventeranno importanti solo nel momento in cui sarà possibile migrare una VM a caldo da o verso un cloud pubblico.

C’è poi una considerazione finale legata ad uno dei possibili casi d’uso, suggeriti da VMware, per questo tipo di vMotion: l’idea di “seguire il sole” (“follow the sun”) ossia di spostare continuamente le VM in base al dove sono più richieste… oppure di spostarle nel datacenter che richiede meno energia per la climatizzazione (ad esempio quello coperto dalle ore notturne… in questo caso diventerebbe pù un “follow the moon”).

Sembra follia o comunque sembra poco praticabile… anche avendo molta banda trasferire ogni volta il contenuto in memoria e su disco di una VM richiede tempo. Ma proviamo a pensare come potrebbe cambiare se invece di dover trasferire ogni volta l’intero contenuto del disco se ne potrebbe trasferire solo una minima parte? I tempi cambierebbero e non poco e questo approccio potrebbe diventare realizzabile!

Ma come si potrebbe ottimizzare lo spostamento dei dischi delle VM? Le tecnologie VMware in realtà già ci sono e basterebbe integrare questo vMotion on qualcosa che periodicamente (o in tempo reale) replichi questi dati… ad esempio la vSphere Replication, ma anche i nuovi Virtual Volumes (con sotto uno storage che replichi i dati). Con questo tipo di integrazione si potrebbe persino migrare live un intero datacenter da un sito ad un altro!

Queste sono solo mie supposizioni su possili servizi e migliorie future… Sicuramente si è aperta una nuova era con queste nuove possibilità offerte dal vMotion in vSphere 6.0!

Andrea Mauro

Virtualization, Cloud and Storage Architect. Tech Field delegate. VMUG IT Co-Founder and board member. VMware VMTN Moderator and vExpert 2010-24. Dell TechCenter Rockstar 2014-15. Microsoft MVP 2014-16. Veeam Vanguard 2015-23. Nutanix NTC 2014-20. Several certifications including: VCDX-DCV, VCP-DCV/DT/Cloud, VCAP-DCA/DCD/CIA/CID/DTA/DTD, MCSA, MCSE, MCITP, CCA, NPP.