This post is also available in: Inglese

Qualche settimana fa ho avuto uno strano problema in un ambiente con VMware vSphere 5.1 dove il vMotion si interrompeva sistematica sul 14% su un particolare host con errori poco chiari. Esistono vari articoli della VMware KB riguardo a problemi simili, ma con ragioni completamente differenti tra loro.

L’errore riportato era un banale messaggio di: Timed out waiting for migration start request. Quindi l’articolo di KB che più si avvicinava era: vMotion fails at 14% with the error: Timed out waiting for migration start request (2068817).

Peccato le le soluzioni proposte non erano applicabili.

Per tutta una serie di ragioni dovute a cattiva pianificazione, il cliente aveva creato le interfacce VMkernel per il vMotion sulla stessa rete di delle interfacce di management (in generale è opportuno che ogni interfaccia VMkernel si trovi su una rete different, ma qua purtroppo la situazione era questa e doveva rimanere così per motivi di gestione del networking inspiegabili, almeno ai miei occhi). Comunque anche provando a spostare temporaneamente le interfacce di vMotion su un’altra rete il problema rimana: un host non era in grado di fare vMotion e liberare le sue VM. Ragionevolmente un riavvio dell’host poteva risolvere il problema, ma dato che vi erano VM in produzione non era un’opzione valida (almeno non durante l’orario lavorativo).

Indagando sui problemi di rete ho poi verificato il più banale degli errori (ma molto tipico quando si ha una cattiva gestione del networking): l’IP assegnato all’interfaccia di vMotion dell’host “difettoso” era usato da un altro sistema in rete e in qualche modo l’host è andato in protezione disattivando l’interfaccia, ma anche disattivando completamente il vMotion. Non ho trovato documentazione a riguardo, ma il comportamento è esattamente questo e probabilmente riguarda tutta la versione 5.x o persino le versioni precedenti.

Purtroppo cancellare l’interfaccia VMkernel del vMotion e crearne una nuova non risolve il problema, come pure non risolve il problema disattivare e ri-attivare il vMotion a livello di host (usando le impostazioni avanzate Migrate / Migrate.enabled), ovviamente senza riavviare l’host. Ma come scritto il riavvio dell’host non era un’opzione percorribile.

Quindi la soluzione è stata agire a livello di CLI e semplicemente lavorare sul modulo del VMkernel che gestisce il vMotion: il modulo si chiama “migrate” e normalmente è caricato (se il vMotion è abilitato). Ma in questo caso non compariva tra i moduli presenti

~ # esxcfg-module -l | grep migrate

Questo modulo non ha alcun parametro di avvio:

~ # esxcfg-module -i migrate
esxcfg-module module information
input file: /usr/lib/vmware/vmkmod/migrate
License: VMware
Version:
Name-space: esx@nover
Required name-spaces:
com.vmware.vmkapi@v2_0_0_0
vmkernel@nover
Parameters:

Quindi se non viene caricato con l’opzione -e:

~ # esxcfg-module -e migrate

L’unica soluzione è caricarlo con il parametro -f:

~ # esxcfg-module -f migrate
Module migrate loaded successfully
~ # esxcfg-module -l | grep migr
migrate 0 320

A questo punto vMotion è tornato a funzionare correttamente.

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.