Come si può aver intuito da precedenti articoli sono un estimatore di VMware, in tutte le sue versioni. Sono stato utente VMware GSX, Server, ESX... ma anche ad esempio XEN, ma sono convinto che ad oggi la migliore scelta sia sempre ESX.
Ci sono giorni come oggi però in cui mi chiedo quale attenzioni dedichino le persone di VMware al lavoro che fanno. Andiamo per ordine: mi ritrovo, senza considerarla una novità, parecchie Virtual Machine con tutti i filesystem in read-only; le macchine stanno bene, non si sono riavviate, ma ad un certo punto hanno ricevuto messaggi satanici dal controller SCSI virtuale e hanno deciso di chiudersi dentro. La soluzione più pratica è un reboot, quella più utile è invece capire perché avvenga e risolvere una volta per tutte il problema.
Il problemino in verità lo conosco da tempo, è anche documentato da VMware stessa, girando la palla al Kernel Linux. Di fatto molti kernel, diffusi soprattutto su RHEL4 e 5, Debian 4.0 ed altre distribuzioni, tendono a mettere in R/O il filesystem se il driver scsi sottostante restituisce lo stato busy per un tempo troppo elevato a causa, per l'appunto, di un bug del driver stesso. Questo tipo di reazione si ha solitamente quando il nodo fisico ESX ha un elevato carico o più semplicemente (a me è capitato questo proprio in fase di test dell'ambiente) in caso di path failover dello storage iSCSI (o FC). Quest'ultimo caso lascia lievemente perplessi, perchè questo tipo di attività dovrebbe essere del tutto trasparente alle macchine virtuali, ma così non è proprio perché per gestire il multipath ESX attende che il path attivo restituisca dei read/write error per poi ritentare le operazioni in coda sul path alternativo, eleggendolo ad attivo.
Tornando a noi, la soluzione è passare al kernel 2.6.22 o superiore; detto fatto, sotto Debian Etch è possibile attingere ai backports e installare un fiammante 2.6.24 mentre su altre distribuzioni si può aggiornare la stessa e trovarsi con versioni omologhe di kernel.
Si passa quindi per la reinstallazione dei VMware Tools che all'apparenza va a buon fine, ESX stesso dice "Tools Ok", ma sotto sotto non è stato ricompilato un bel nulla visto che ci si ritrova senza vmnet e vmmctl driver, per non parlare (dell'inutile) vmhgfs. In pratica i VMware Tools non sono compatibile con questa versione di kernel, nonostante sia VMware stessa che ti spinga verso versioni più recenti.
Una soluzione, che ovviamente non mi sono inventato io ma che riporto in lingua italiana qui, è la seguente:
Il risultato che si ottiene è semplicemente... una installazione dei VMware Tools funzionante.