Come verificare se VMware Tools è installato su Linux

Se devi capire in fretta se VMware Tools è presente su una macchina Linux, non partire dal pannello vSphere e non fidarti di un solo indicatore. In pratica conviene verificare tre livelli: il pacchetto installato nel sistema, il servizio attivo e la risposta dell’host tramite gli strumenti VMware. Se questi tre segnali tornano, hai quasi sempre una conferma solida. Se ne manca uno, non è ancora prova di assenza: può esserci una versione diversa del pacchetto, un servizio disabilitato o un guest tools minimale già integrato nella distribuzione.

La distinzione importante è questa: su Linux moderno puoi incontrare VMware Tools classico, open-vm-tools oppure componenti installati dal vendor della distribuzione. Dal punto di vista operativo, quello che ti interessa è sapere se il guest espone le funzioni attese: stato, heartbeat, sincronizzazione oraria, shutdown ordinato, reporting IP e, in alcuni casi, resize o integrazione mouse/video. Quindi la verifica va fatta con metodo, non con un singolo comando “magico”.

1. Prima distinzione: VMware Tools classico o open-vm-tools

Su molte distribuzioni Linux attuali, soprattutto quelle recenti, la risposta corretta non è “VMware Tools sì/no”, ma “quale implementazione è installata”. In ambiente VMware, open-vm-tools è spesso la scelta standard supportata dal sistema operativo, mentre il pacchetto legacy VMware Tools può essere ancora presente in ambienti più vecchi o in installazioni manuali.

Per questo la prima verifica utile è il pacchetto gestito dal sistema. Se trovi open-vm-tools, nella maggior parte dei casi la macchina ha già l’integrazione necessaria. Se invece trovi i pacchetti VMware storici, la verifica cambia leggermente perché i nomi dei servizi e dei binari possono differire. Non dare per scontato che la presenza del driver video o di un modulo kernel significhi che tutte le funzioni guest siano operative: serve controllare anche il demone utente.

2. Verifica dal sistema operativo: pacchetti installati

Il controllo più pulito è partire dal package manager. Su Debian, Ubuntu e derivate:

dpkg -l | grep -E 'open-vm-tools|vmware-tools'

Su RHEL, CentOS, AlmaLinux, Rocky e derivate:

rpm -qa | grep -E 'open-vm-tools|VMwareTools|vmware-tools'

Su SUSE:

zypper se -i -t package | grep -E 'open-vm-tools|vmware-tools'

Interpretazione pratica:

• open-vm-tools presente: in genere sei già a posto per l’integrazione base con VMware.
• VMware Tools legacy presente: il guest usa il pacchetto classico, spesso installato manualmente o da ISO VMware.
• Nessun pacchetto trovato: non significa automaticamente assenza totale di integrazione, ma è un forte indizio che i tools non siano installati nel sistema.

Se il sistema è minimale o containerizzato, il package manager può non essere disponibile o può non contenere il software guest. In quel caso la verifica va spostata sul servizio e sulla presenza dei binari.

3. Verifica dal sistema operativo: servizio systemd

Su Linux con systemd, il segnale più affidabile è lo stato del servizio. I nomi più comuni sono open-vm-tools e, in alcuni ambienti, servizi legati al vecchio stack VMware.

systemctl status open-vm-tools --no-pager

Se il pacchetto è installato e il servizio è attivo, dovresti vedere qualcosa del tipo active (running). Se invece ottieni Unit open-vm-tools.service could not be found, hai due possibilità: il pacchetto non è installato oppure la distribuzione usa un nome diverso per il servizio.

systemctl list-unit-files | grep -i vmware
systemctl list-units --type=service | grep -i vmware

Su alcune distribuzioni il demone può essere gestito come servizio diverso o integrato in un metapacchetto. Il punto operativo è verificare che ci sia un processo attivo che faccia da ponte tra guest e hypervisor. Senza demone, molte funzioni di integrazione non sono disponibili anche se alcuni componenti sono installati sul disco.

Se vuoi una conferma rapida con output leggibile, puoi anche cercare il processo:

ps -ef | grep -E 'vmtoolsd|vmware-toolbox|open-vm-tools' | grep -v grep

Qui il nome più interessante è spesso vmtoolsd, il demone che fornisce parte dell’integrazione guest. La presenza del solo processo non basta a dire che tutto funzioni, ma è una buona conferma che i tools non sono solo installati: sono anche in esecuzione.

4. Verifica funzionale: comando vmware-toolbox-cmd e stato guest

Quando il pacchetto è presente, il test più diretto è usare gli strumenti inclusi. Su molte installazioni con open-vm-tools trovi vmware-toolbox-cmd. È utile perché non si limita a dirti “c’è un file”: interroga il demone e ti dà informazioni di stato.

vmware-toolbox-cmd -v
vmware-toolbox-cmd stat raw

Il primo comando ti dice se il binario esiste e quale versione espone. Il secondo può variare in base alla distribuzione e alla versione, ma l’idea è verificare che il tool riesca a parlare con il servizio guest. Se il comando risponde con errori di connessione al socket o con un messaggio di servizio non disponibile, i componenti potrebbero essere installati ma non operativi.

Un altro controllo utile è la presenza dei comandi di supporto nei percorsi standard:

command -v vmtoolsd
command -v vmware-toolbox-cmd
command -v vmware-user

Se questi binari sono presenti, hai un’indicazione forte. Se mancano, spesso il pacchetto non è installato o è stato rimosso. In ambienti con immagini golden o template, il controllo dei binari è anche un modo rapido per verificare che la macchina sia stata clonata con il set corretto di componenti guest.

5. Verifica lato VMware: da vSphere o ESXi

Se hai accesso al pannello VMware, il guest status è il secondo segnale da controllare. Nel client vSphere la VM mostra spesso lo stato di VMware Tools con indicatori tipo Running, Not running o Not installed. Questo dato è utile, ma va letto con prudenza: il pannello dipende dal reporting del guest. Se il demone è bloccato o la rete di management è degradata, potresti vedere uno stato non aggiornato.

La verifica operativa si fa così: apri la VM, controlla la scheda riepilogo o la sezione relativa allo stato guest, e confronta l’indicazione con ciò che vedi dal sistema operativo. Se il pannello dice Installed and running ma il comando locale non trova i binari, hai probabilmente una discrepanza dovuta a snapshot, clone o stato cache del management plane. Se il pannello dice Not installed ma il pacchetto è presente nel guest, il demone potrebbe essere fermo o il reporting potrebbe non essere ancora arrivato all’host.

In ambienti ESXi, l’host può mostrare anche dettagli come versione tools, IP address guest e heartbeat. Questi campi sono utili per una verifica incrociata, soprattutto quando stai diagnosticando problemi di rete o di shutdown ordinato. Se l’IP del guest non compare, non significa automaticamente che VMware Tools manchi: può dipendere da permessi, rete guest o ritardo di aggiornamento.

6. Controllo dei log quando la risposta è ambigua

Se i comandi precedenti non bastano, vai sui log. In genere il punto giusto è il journal di systemd o i log specifici del demone. Su una macchina con open-vm-tools puoi partire da:

journalctl -u open-vm-tools -b --no-pager

Se non trovi l’unità, cerca nei log di sistema:

journalctl -b | grep -i vmware
journalctl -b | grep -i vmtools

Su installazioni legacy o manuali possono esistere file diversi, ma i sintomi tipici sono simili: errori sul socket, mancato avvio del demone, mismatch tra versione del kernel e moduli, oppure problemi con i servizi desktop se la macchina ha interfaccia grafica. Il log ti dice se il pacchetto c’è ma non parte, oppure se il problema è a valle, per esempio una dipendenza mancante o una policy di sistema che blocca l’avvio.

Un esempio concreto: se systemctl status open-vm-tools mostra disabled o inactive (dead), il pacchetto è presente ma non operativo. Se il journal riporta errori di avvio, hai la prova che il problema non è “installato/non installato”, ma “installato/non funzionante”. Questa differenza fa risparmiare tempo, soprattutto quando il ticket è solo “VMware Tools non va”.

7. Metodo rapido in 5 minuti: checklist pratica

Se devi fare una verifica secca, usa questo ordine. È veloce e ti evita falsi positivi.

1. Controlla il pacchetto installato con dpkg -l, rpm -qa o zypper se -i.
2. Controlla il servizio con systemctl status open-vm-tools.
3. Verifica i binari con command -v vmtoolsd e command -v vmware-toolbox-cmd.
4. Se sei su vSphere, confronta lo stato guest nel pannello con l’output locale.
5. Se c’è discordanza, vai su journalctl -u open-vm-tools -b o sul journal di sistema.

Questo ordine funziona perché parte dal dato più stabile, cioè il pacchetto, passa al runtime, e solo alla fine guarda il layer di management esterno. È il contrario di quello che fanno molti operatori alle prime armi, che aprono il pannello VMware e si fermano lì. In produzione è un errore: il pannello è utile, ma non è la sorgente unica di verità.

8. Casi particolari che confondono la verifica

Ci sono situazioni in cui il controllo sembra contraddittorio. La prima è il guest appena avviato: il servizio può essere attivo ma il pannello non ha ancora aggiornato lo stato. La seconda è una VM clonata da template: il pacchetto può esserci, ma il demone va inizializzato o ripulito da configurazioni precedenti. La terza è una distribuzione con pacchetto integrato nel sistema base, dove il nome del servizio o dei binari non coincide con i documenti più vecchi trovati online.

Un altro caso frequente è il desktop Linux con sessione grafica. Alcuni componenti, come l’integrazione mouse o il copia-incolla, dipendono anche dal lato utente. Quindi un servizio attivo non garantisce che tutte le feature desktop siano visibili subito nella sessione. Se il tuo obiettivo è solo sapere se i tools sono installati, non farti distrarre da funzionalità collaterali.

Infine, attenzione alle immagini cloud o alle appliance virtuali già preconfezionate. In certi casi l’admin non ha installato nulla manualmente, ma il vendor ha incluso open-vm-tools per default. La conferma va sempre fatta nel sistema operativo reale, non nelle note del template.

9. Se non trovi nulla: cosa significa davvero

Se il package manager non mostra nulla, il servizio non esiste, i binari non sono presenti e il pannello VMware indica Not installed, allora la conclusione è ragionevolmente solida: VMware Tools non sono installati nel guest. A quel punto puoi decidere se installare open-vm-tools dal repository della distribuzione oppure il pacchetto specifico richiesto dal tuo standard interno.

Se invece hai segnali misti, non forzare una conclusione immediata. Ad esempio: pacchetto presente ma servizio down, oppure servizio attivo ma il pannello non aggiorna. In quel caso il problema non è la sola installazione, ma la salute del demone o la comunicazione guest-host. La diagnosi corretta distingue sempre tra presenza, avvio e funzionamento.

10. Esempio operativo completo

Su un server Ubuntu, per esempio, puoi fare così:

dpkg -l | grep -E 'open-vm-tools|vmware-tools'
systemctl status open-vm-tools --no-pager
command -v vmware-toolbox-cmd
vmware-toolbox-cmd -v
journalctl -u open-vm-tools -b --no-pager

Se il primo comando restituisce una riga con open-vm-tools, il secondo mostra active (running), il terzo trova il binario e il quarto risponde con una versione, hai una conferma molto forte che VMware Tools, nella forma open-vm-tools, sono installati e operativi. Se uno dei passaggi fallisce, il punto esatto del guasto è già abbastanza chiaro per decidere il passo successivo.

Su una macchina RHEL-like il flusso è identico, cambia solo il comando per vedere i pacchetti. Anche qui la regola resta la stessa: non fermarti al solo stato del pannello e non basarti su un solo binario. La verifica robusta combina package, servizio, processo e, se disponibile, feedback da vSphere.

11. Conclusione operativa da tenere in testa

Per sapere se VMware Tools è installato su Linux, la strada più pulita è verificare il pacchetto, poi il servizio, poi il comportamento del demone e infine il riscontro lato VMware. Se tutti i livelli concordano, hai una risposta affidabile. Se non concordano, il problema non è solo “installato o no”: spesso è un servizio fermo, un reporting ritardato o un’installazione incompleta. In pratica, la diagnosi buona non cerca un sì/no immediato: cerca un insieme di prove coerenti.