Què fer quan una VM no arrenca a VMware

No totes les VMs que no arrenquen ho fan pel mateix motiu. Algunes fallen amb una pantalla clara, d’altres es queden congelades a l’splash del BIOS, i d’altres directament desapareixen de la llista de processos actius sense deixar log.

El 90% dels problemes no estan en el manual sinó en els detalls: un datastore que es va desanexionar, un snapshot oblidat o una vNIC mal assignada. La idea és repassar què revisar quan una VM es nega a arrencar, però de forma centrada en el que sí que passa en producció.

1. Primer, confirmar el tipus de fallada

Abans de començar a moure fitxers o reiniciar serveis, convé acotar el tipus de fallada. La VM:

• No apareix com a encesa encara que ho intentes?
• Retorna errors en encendre-la (pantalla negra, BIOS sense boot)?
• Queda penjada durant POST?
• Mostra errors dins del SO però sí que arrenca?

Encara que soni obvi, de vegades malgastem temps anant a logs d’ESXi quan l’error estava al SO de la VM. Així que comença per definir si el problema és:

• De VMware (maquinari virtual, configuració, emmagatzematge, snapshot, lock d’arxius)
• De xarxa (vSwitch mal assignat, NIC virtual desconnectada)
• O del sistema operatiu (corrupció de l’arrencada, disc ple, serveis crítics caiguts)

2. El datastore i les seves trampes: comprovar l’accessibilitat real

Si la VM no s’encén i no hi ha missatge clar, sospita de l’emmagatzematge. En entorns on fem servir NFS, iSCSI o fins i tot vSAN, no és estrany que el datastore estigui visible en l’inventari però tingui errors a sota. Coses a revisar:

• ¿Pots explorar el datastore des del navegador d’arxius del host?
  • Si en obrir la carpeta de la VM tarda més d’un parell de segons o llança error, és mal senyal. De vegades el datastore apareix “mounted” però té I/O freeze parcial per una fallada en el backend d’emmagatzematge.
• Revisa els logs del host a /var/log/vmkernel.log o vmkwarning.log
  • Busca línies amb “APD” (All Paths Down) o “PDL” (Permanent Device Loss). Si veus això, tens un problema de connectivitat d’emmagatzematge més seriós que la VM en si.
• Verifica que els VMDK estiguin accessibles
  • Desde SSH al host: ls -lh /vmfs/volumes/[datastore]/[vmname]/*.vmdk
  • Si el comandament es penja o retorna I/O error, és un símptoma clar de problemes de disc subjacent.

Una VM no arrencarà si el seu disc virtual està bloquejat, corromput o apunta a un delta desaparegut. Això ens porta al següent punt.

3. Snapshots mal tancats o inconsistents

Aquest és un clàssic. Especialment en entorns on es fan backups amb solucions que fan servir snapshots (Veeam, Nakivo, Rubrik…). Si un snapshot es queda penjat, o no s’esborra bé, la cadena de deltes pot quedar trencada.

Símptomes habituals:

• Error genèric en encendre: “File not found” encara que els arxius estiguin allà.
• L’arxiu .vmx fa referència a un -000001.vmdk que ja no existeix.
• Una cadena de VMDKs que no té un “base disk” al final (o que té diversos layers amb errors).

Solució típica:

• Revisa el .vmx i assegura’t que els discos  referencien al delta correcte.
• Fes servir vmkfstools -i per a clonar el delta actual a un nou VMDK net si és necessari.
• Si l’snapshot existeix en inventari, intenta consolidar-lo (botó dret > Snapshot > Consolidate).
• Si això falla, i pots assumir downtime, apaga la VM i consolida des de línia de comandaments: vmkfstools –merge.

Molt de compte amb eliminar snapshots des del datastore sense conèixer l’ordre de la cadena. Pots perdre dades reals, no només deltes.

4. Lock d’arxius: un detall que sempre fa perdre temps

Si una altra instància del hypervisor té lock sobre els arxius de la VM (típic en clusters mal configurats o després d’una fallada de HA), la VM no arrencarà encara que sembli que tot està bé.

Què revisar:

• Veus errors tipus ” The operation is not allowed in the current state “?
• En intentar encendre, diu que l’arxiu VMDK o VMX està bloquejat?

Des de SSH, pots fer servir:

vmkfstools -D /vmfs/volumes/datastore/vm/vm.vmdk

Això mostra quin host té el lock. De vegades és un que ja no està actiu o es va reiniciar malament.

Solució:

• Si el host que té el lock està apagat o ja no té la VM registrada, pots reiniciar els serveis de gestió al host ESXi (si no afecta altres VMs):

services.sh restart 

o en hosts més nous:

/etc/init.d/hostd && /etc/init.d/vpxa restart

• Si estàs en un entorn amb vCenter, desconnecta i reconnecta el host que té el lock, si és segur fer-ho.

5. Errors de maquinari virtual o versions incompatibles

Un altre motiu comú, sobretot després de migracions o restauracions, és que la VM estigui configurada amb una versió de maquinari virtual incompatible amb el host.

Símptomes:

• Pantalla negra en arrencar, sense POST.
• Error en intentar engegar: ” This virtual machine requires hardware version XX which is not supported.

Solució ràpida:

• Edita el .vmx i canvia:

virtualHW.version = "13"

… a una versió que el host suporti (consulta la matriu de compatibilitat de VMware). La versió 13, per exemple, és segura per a ESXi 6.5.

• Si l’edites des de vSphere, assegura’t d’apagar la VM abans. Molts canvis no s’apliquen en calent.

6. Fallada en la controladora de disc virtual

En restauracions des de backup o canvis manuals en el maquinari de la VM, és habitual que es tregui la controladora de disc (LSI Logic, per a SCSI, per exemple) sense tornar a afegir-la.

Símptomes:

• VM arrenca al BIOS i diu que no hi ha disc.
• El disc virtual apareix assignat però la VM no booteja.

Què revisar:

• Veu les opcions de maquinari de la VM. Si el VMDK apareix però no hi ha controladora, tens el problema clar.
• Afegeix una nova SCSI controller del tipus que espera el SO convidat (LSI Logic SAS per a Windows recents, BusLogic per a Linux antics, etc.)

7. Config entries heretats o inconsistents al .vmx

En entorns amb scripting, generació de VMs per API o migracions manuals, l’arxiu .vmx pot arrossegar entrades antigues o contradictòries que impedeixen l’arrencada.

Revisar:

• Entrades d’ ethernetX.virtualDev, scsiX.present, ideX: 0.deviceType, etc.
• Línies duplicades o mal tancades.

Si el .vmx està massa brut o no arrenca ni reconfigurant, moltes vegades és més net:

• Crear una nova VM amb la mateixa config (RAM, CPU, disc)
• Apagar-la, esborrar el seu .vmdk
• Copiar el .vmdk de la VM original
• Registrar la nova VM apuntant al disc vell

Això et dona un entorn net sense perdre el disc.

8. Logs útils a on mirar

Els logs més útils solen estar en:

• /vmfs/volums/datastore/vmname/vmware.log
• /var/log/vmkernel.log
• /pes/log/hosted.Log
• /war/people/vp.a. people (si fas servir vCenter)

Quan l’ error és críptic, busca per:

• Could not open/create change tracking file
• Cannot open the disk ‘xyz.vmdk’ or one of the snapshot disks it depends on.
• Failed to power on virtual machine: Lock was not free.

Si hi ha un vmware.log a la carpeta de la VM, comença aquí. Els errors solen estar cap al final, just abans de l’intent fallit de power-on.

9. Coses s’haurien d’evitar

• Reiniciar el host sense comprovar si hi ha altres VMs crítiques. Moltes vegades el problema està en un lock o un error de configuració que un reboot no resol i a més deixa altres serveis a l’aire.
• Moure manualment tots els arxius d’una VM trencada a un altre datastore sense revisar dependències. Si hi havia snapshots o discos en diversos datastores, això només complica més l’assumpte.
• Tornar a registrar la VM sense revisar quins arxius estan corruptes o falten. Si no hi ha .vmdk o està incomplet, l’únic que aconsegueixes és un placeholder buit.

Conclusió

La clau està en no disparar primer. Una VM que no arrenca pot fallar per moltes raons, però la majoria tenen senyals clars si se saben llegir els logs i es té context del que s’ha fet en l’entorn (backups recents, tasques programades, expansions de discos, etc.). I gairebé sempre, amb una revisió ordenada, es pot recuperar sense pèrdua de dades ni recrear des de zero.

Si treballes amb snapshots, clons i entorns híbrids, val la pena automatitzar una revisió de consistència de discos i estat de datastores. No evita totes les fallades, però redueix els ensurts.